Thread: A notice for too long names
Wouldn't it be fair if a notice was generated if you attempt to create and/or reference a name that's longer than NAMEDATALEN. Like => create table some_really_much_too_long_name_here ( ... ); NOTICE: "some_really_much_too_long_name_here" will be truncated to "some_really_much_too_long_name_" [ <possible reference to documentation and/or source code to change this> ] Better than finding out after the fact, ISTM. I could (try to) take care of this. -- Peter Eisentraut Sernanders vaeg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
> Wouldn't it be fair if a notice was generated if you attempt to create
> and/or reference a name that's longer than NAMEDATALEN. Like
>
> => create table some_really_much_too_long_name_here ( ... );
> NOTICE: "some_really_much_too_long_name_here" will be truncated to
> "some_really_much_too_long_name_" [ <possible reference to documentation
> and/or source code to change this> ]
> Better than finding out after the fact, ISTM. I could (try to) take care
> of this.
Would it be better to throw an elog(ERROR)? The only place I know of
where names are silently truncated is in generating primary and unique
indices, where the names are based on the underlying table name plus
some automatically generated discriminator.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
>> Wouldn't it be fair if a notice was generated if you attempt to create
>> and/or reference a name that's longer than NAMEDATALEN.
> Would it be better to throw an elog(ERROR)?
Definitely NOT. Rejecting long identifiers went out with Dartmouth Basic.
The only reason to worry at all is if someone uses two identifiers that
are the same for the first NAMEDATALEN characters --- but if so, he'll
get an error about duplicate column or duplicate table name. I see no
real reason to change the current behavior...
regards, tom lane
On 2000-01-20, Tom Lane mentioned: > Thomas Lockhart <lockhart@alumni.caltech.edu> writes: > >> Wouldn't it be fair if a notice was generated if you attempt to create > >> and/or reference a name that's longer than NAMEDATALEN. > > > Would it be better to throw an elog(ERROR)? > > Definitely NOT. Rejecting long identifiers went out with Dartmouth Basic. But it came back with compilers issuing warnings (hence notice) about them. Silently truncating input went out with GNU, so I guess it's more of a current trend ... :) -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
At 10:54 PM 1/20/00 +0100, Peter Eisentraut wrote: >On 2000-01-20, Tom Lane mentioned: > >> Thomas Lockhart <lockhart@alumni.caltech.edu> writes: >> >> Wouldn't it be fair if a notice was generated if you attempt to create >> >> and/or reference a name that's longer than NAMEDATALEN. >> >> > Would it be better to throw an elog(ERROR)? >> >> Definitely NOT. Rejecting long identifiers went out with Dartmouth Basic. > >But it came back with compilers issuing warnings (hence notice) about >them. Silently truncating input went out with GNU, GNU C was hardly the first compiler to correctly handle identifiers of virtually any length. I doubt if it even makes the list of the first 100... (I get tired of GNU-worship) How deeply embedded is the limitation on identifier length? Ideal would be to remove any artificial limitation whatsoever. The current situation isn't bad, since name clashes are rare - it's not as though PostgreSQL is only keeping the first six characters like Fortran 66! Still, all such limitations are fundamentally irksome. - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert Serviceand other goodies at http://donb.photo.net.