"Greg Sabino Mullane" <greg@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
