On 14/01/16 13:05, Tom Lane wrote:
> Thomas Munro <thomas.munro@enterprisedb.com> writes:
>> Wouldn't it be better to raise an error when identifiers are too long,
>> rather than accepting but truncating them?
> I wouldn't think so.
>
>> I'm not aware of any other database that does this.
> It's standard practice in most programming languages AFAIK. And SQL is
> surely a programming language.
>
>> If you're using oversized identifiers you
>> could finish up using more than one way to refer to the same database
>> object, and then your queries will have a different meaning if
>> NAMEDATALEN ever changes.
> No, they'd just start failing if they didn't match the object (which
> there can be only one of, else you'd have gotten other errors).
>
> Another argument against comes from the fact that NAMEDATALEN is usually
> less than what SQL says is the minimum required length (viz, 128
> characters). Your proposal would have us throwing entirely needless
> errors on queries that are fully spec-conformant.
>
> regards, tom lane
>
>
I would prefer a database to be more strict.
How about a GUC to control this behaviour, with the default to be lax?
Cheers,
Gavin
