Re: Truncation of identifiers

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

In response to

Browse pgsql-hackers by date

  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