[HACKERS] Truncation of identifiers

2016-01-13 Thread Thomas Munro
Hi hackers

Wouldn't it be better to raise an error when identifiers are too long,
rather than accepting but truncating them?  I'm not aware of any other
database that does this.  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.  If you're automatically generating
identifier names (say for partitioning), wouldn't you rather find out
about the size being too long immediately, rather than later when you
try to generate a second long name that collides with the first after
truncation?  I suppose there could be a GUC
truncate_oversized_identifiers defaulting to off, which could be
turned on by those who really prefer the current
truncate-but-raise-NOTICE behaviour.

-- 
Thomas Munro
http://www.enterprisedb.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Truncation of identifiers

2016-01-13 Thread Tom Lane
Thomas Munro  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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Truncation of identifiers

2016-01-13 Thread Gavin Flower

On 14/01/16 13:05, Tom Lane wrote:

Thomas Munro  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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers