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



Tue, 13 Jun 2000 18:41:42 -0700
"G. Anthony Reina" <reina@nsi.edu>
7.0.2 cuts off attribute name
"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

Tue, 13 Jun 2000 22:59:26 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: 7.0.2 cuts off attribute name 

> 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 endorsed by 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.
***********************************************************************

Wed, 14 Jun 2000 10:39:39 +0100
Niall Smart <niall.smart@ebeon.com>
Re: 7.0.2 cuts off attribute name
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

Wed, 14 Jun 2000 08:12:00 -0400
"Mark Hollomon" <mhh@nortelnetworks.com>
Re: 7.0.2 cuts off attribute name
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

Wed, 14 Jun 2000 11:23:42 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: 7.0.2 cuts off attribute name 
"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

Wed, 14 Jun 2000 11:28:43 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: 7.0.2 cuts off attribute name 
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



Wed, 14 Jun 2000 10:41:58 -0700
"G. Anthony Reina" <reina@nsi.edu>
Re: 7.0.2 cuts off attribute name
"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

Wed, 14 Jun 2000 15:06:34 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: 7.0.2 cuts off attribute name 
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

Thu, 15 Jun 2000 10:38:22 +1200
Andrew McMillan <Andrew@catalyst.net.nz>
Re: 7.0.2 cuts off attribute name
> "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

Thu, 15 Jun 2000 22:05:16 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: 7.0.2 cuts off attribute name 