Обсуждение: 7.0.2 cuts off attribute name
I just upgraded to 7.0.2. Everything looks fine, except for one (annoying) change. I have an attribute in a table named "significance_of_anova_for_spike_rates". (I know, I know. I get laughed at all the time for using prepositions in my variable names). In 6.5.1 and before, Postgres took the whole name as the identifier. With 7.0.2 it seems to truncate to "significance_of_anova_for_spike" (31 characters). Is there any reason that this has changed? Anyway to get a larger length (say 40 or 50 characters)? Thanks. -Tony Reina
"G. Anthony Reina" <reina@nsi.edu> writes:
> "significance_of_anova_for_spike_rates". (I know, I know. I get laughed
> at all the time for using prepositions in my variable names). In 6.5.1
> and before, Postgres took the whole name as the identifier. With 7.0.2
> it seems to truncate to "significance_of_anova_for_spike" (31
> characters).
What? The default length limit has been 31 characters for a long time,
certainly long before 6.5.*.
7.0 has a new behavior of *telling* you that it's truncating overlength
identifiers, but the system has always truncated 'em.
If you're simply complaining about the fact that it emits a notice,
I agree with you 100%: that notice is one of the most nonstandard,
useless, annoying bits of pointless pedantry I've seen in many years.
I argued against it to start with but was outvoted. Maybe we can have
a revote now that people have had some practical experience with it:
who still thinks it's a good idea?
> Is there any reason that this has changed? Anyway to get a larger length
> (say 40 or 50 characters)?
You could recompile with a larger NAMEDATALEN, but unless you did so in
your 6.5.* installation, that's not what's bugging you. Look for the
elog(NOTICE,...) call in src/backend/parser/scan.l and dike that out,
instead.
regards, tom lane
Tom Lane wrote: > > 7.0 has a new behavior of *telling* you that it's truncating overlength > identifiers, but the system has always truncated 'em. > > If you're simply complaining about the fact that it emits a notice, > I agree with you 100%: that notice is one of the most nonstandard, > useless, annoying bits of pointless pedantry I've seen in many years. > I argued against it to start with but was outvoted. Maybe we can have > a revote now that people have had some practical experience with it: > who still thinks it's a good idea? And while we're at it, let's get rid of the 'implementation' NOTICEs about foreign keys and UNIQUE. I don't mind the NOTICE about SERIAL since we don't clean up the sequence on DROP TABLE. -- Mark Hollomon mhh@nortelnetworks.com ESN 451-9008 (302)454-9008
> 7.0 has a new behavior of *telling* you that it's truncating overlength > identifiers, but the system has always truncated 'em. > > If you're simply complaining about the fact that it emits a notice, > I agree with you 100%: that notice is one of the most nonstandard, > useless, annoying bits of pointless pedantry I've seen in many years. > I argued against it to start with but was outvoted. Maybe we can have > a revote now that people have had some practical experience with it: > who still thinks it's a good idea? You think it should fail with an error message instead? ;) I think that PostgreSQL must tell the user when it is doing something as significant as truncating a name. Niall *********************************************************************** Privileged/confidential information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and notify the sender and postmaster@ebeon.com immediately. If you or your employer do not consent to Internet E-mail messages of this kind, please advise us immediately. Opinions, conclusions and other information expressed in this message(including any attachments) are not given or endorsedby ebeon ltd(or ebeon inc., as applicable) unless otherwise confirmed in writing by an authorised representative independent of this message. Any liability arising from reliance placed on this message (including its attachments) without such independent confirmation is hereby excluded. This message (including attachments) is protected by copyright laws but has no other legal or contractual standing. The presence of this footnote indicates that this message (including its attachments) has been processed by an automated anti-virus system; however it is the responsiblity of the recipient to ensure that the message (and attachments) are safe and authorised for use in their environment. ***********************************************************************
Niall Smart <niall.smart@ebeon.com> writes:
>> 7.0 has a new behavior of *telling* you that it's truncating overlength
>> identifiers, but the system has always truncated 'em.
> You think it should fail with an error message instead? ;)
> I think that PostgreSQL must tell the user when it is doing
> something as significant as truncating a name.
But the point is that it is *not* significant, at least not in 99.99%
of cases. Truncating identifiers has been a standard compiler practice
for decades, and nobody emits warnings when they do it.
The reason it's not significant is that there is no problem unless you
actually have a conflict caused by truncation, and in that scenario you
will get an appropriate error message. For example:
create table foo (a_very_very_really_long_identifier_foo int,
a_very_very_really_long_identifier_bar float);
NOTICE: identifier "a_very_very_really_long_identifier_foo" will be truncated to "a_very_very_really_long_identif"
NOTICE: identifier "a_very_very_really_long_identifier_bar" will be truncated to "a_very_very_really_long_identif"
ERROR: CREATE TABLE: attribute "a_very_very_really_long_identif" duplicated
Now when you get an error like that, it doesn't take a rocket scientist
to figure out that the problem is the system's only paying attention to
the first N characters; do you really need the "help" of the notices
for that?
The rest of the time, when there isn't a naming conflict, the notices
are just useless noise.
I have never heard of another programming language implementation that
emits notices when truncating overlength identifiers to fit in its
symbol table. The reason why Postgres is alone in doing this is *not*
that we're smarter than everybody else.
regards, tom lane
"Mark Hollomon" <mhh@nortelnetworks.com> writes:
> And while we're at it, let's get rid of the 'implementation' NOTICEs
> about foreign keys and UNIQUE.
> I don't mind the NOTICE about SERIAL since we don't clean up the
> sequence on DROP TABLE.
Hmm, I could vote for that.
Perhaps the right solution would be to downgrade messages like this
to a new elog level (of severity between NOTICE and DEBUG), and then
add a "verbosity" SET variable that allows the user to choose whether
to see 'em or not. It'd be nice to be able to choose to get DEBUG
messages sent to the frontend, too, instead of only going to the
postmaster log.
regards, tom lane
Tom Lane wrote: > 7.0 has a new behavior of *telling* you that it's truncating overlength > identifiers, but the system has always truncated 'em. > Yes, I see now in my backups that 6.5.1 was truncating at 31 characters but just wasn't telling me. I wasn't aware if the limit. So it is nice to have the notice, but perhaps should only show up once (e.g. when the table is initially created). That way, once you've been advised of the truncation, it won't annoy you any longer. > > > Is there any reason that this has changed? Anyway to get a larger length > > (say 40 or 50 characters)? > > You could recompile with a larger NAMEDATALEN, but unless you did so in > your 6.5.* installation, that's not what's bugging you. Look for the > elog(NOTICE,...) call in src/backend/parser/scan.l and dike that out, > instead. > I tried changing NAMEDATALEN in the postgres_ext.h to 52. Everything compiled and installed fine, but the initdb failed. Maybe there is more to it than just changing that one constant. Anyway, I've gone back to the original NAMEDATALEN = 32 and will just rename my field to something smaller than 31 chars. -Tony
"G. Anthony Reina" <reina@nsi.edu> writes:
> I tried changing NAMEDATALEN in the postgres_ext.h to 52. Everything compiled
> and installed fine, but the initdb failed. Maybe there is more to it than
> just changing that one constant.
Hmm, AFAIK that's supposed to work. I'll give it a try sometime ---
maybe some dependency has snuck in somewhere.
regards, tom lane
Tom Lane wrote: > > "Mark Hollomon" <mhh@nortelnetworks.com> writes: > > And while we're at it, let's get rid of the 'implementation' NOTICEs > > about foreign keys and UNIQUE. > > I don't mind the NOTICE about SERIAL since we don't clean up the > > sequence on DROP TABLE. > > Hmm, I could vote for that. > > Perhaps the right solution would be to downgrade messages like this > to a new elog level (of severity between NOTICE and DEBUG), and then > add a "verbosity" SET variable that allows the user to choose whether > to see 'em or not. It'd be nice to be able to choose to get DEBUG > messages sent to the frontend, too, instead of only going to the > postmaster log. severity 'PEDANTIC' :-) Andrew. -- _____________________________________________________________________ Andrew McMillan, e-mail: Andrew@cat-it.co.nz Catalyst IT Ltd, PO Box 10-225, Level 22, 105 The Terrace, Wellington Me: +64 (21) 635 694, Fax: +64 (4) 499 5596, Office: +64 (4) 499 2267
> "G. Anthony Reina" <reina@nsi.edu> writes:
>> I tried changing NAMEDATALEN in the postgres_ext.h to 52. Everything compiled
>> and installed fine, but the initdb failed. Maybe there is more to it than
>> just changing that one constant.
> Hmm, AFAIK that's supposed to work. I'll give it a try sometime ---
> maybe some dependency has snuck in somewhere.
I built current sources with NAMEDATALEN = 52 and didn't see any
problem. Regression tests all passed except for a couple of differences
in the 'name' test --- not too surprising since it was checking for
truncation of names at 31 chars...
You may not have done the build properly. Usually on a reconfiguration
the only safe way is "make clean" and "make all". We don't have
adequate dependency info in the Makefiles to ensure a full rebuild
without "make clean". (I think Peter E. is hoping to fix that soon,
but for now that's how you gotta do it.)
regards, tom lane