From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | 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 00:05:30 |
Message-ID: | 18566.1452729930@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2016-01-14 00:30:31 | Re: Removing Functionally Dependent GROUP BY Columns |
Previous Message | Thomas Munro | 2016-01-13 22:26:48 | Truncation of identifiers |