"Greg Sabino Mullane" <g...@turnstep.com> writes:
>> If it's a postgres bug, what is the fix? Make the identifier max size
>> longer?
> I'd also be in favor of this, in addition to upgrading from a NOTICE.
Increasing NAMEDATALEN has been discussed, and rejected, before. It
is very very far from being a free change: it would double the storage
space required for "name" columns, which is a sizable fraction of the
space eaten in the pg_class and pg_attribute catalogs. (Or we could
convert "name" to a variable length type, but the fallout from that
would vastly exceed what this feature seems worth.)
I think there probably is some case for treating overlength names as
errors not warnings, but on the other hand there's a case for fearing
this will break applications that work fine today. In particular, it
would break applications that expect to be able to use spec-compliant
128-character names, *whether or not they actually have any collisions*.
That seems pretty undesirable, especially in view of the fact that
duplicate-name checks would catch any actual collisions in most cases.
Another point here is that appealing to the letter of the spec in this
area is a bit dubious anyway given the number of ways in which we vary
from exact spec compliance --- notably, allowing non-ASCII characters in
identifiers, allowing dollar signs, allowing leading underscore (no,
that's not per spec), folding to lower case not upper case.
On the whole I'm not too excited about changing this.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
