From: | Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Truncation of identifiers |
Date: | 2016-01-14 01:08:36 |
Message-ID: | 5696F514.6000607@archidevsys.co.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 14/01/16 13:05, Tom Lane wrote:
> Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2016-01-14 03:37:04 | Re: Python 3.x versus PG 9.1 branch |
Previous Message | David Rowley | 2016-01-14 00:30:31 | Re: Removing Functionally Dependent GROUP BY Columns |