Is there a drawback when changing NAMEDATALEN to 64?

Frank Joerdens <frank@joerdens.de> writes:

Is there a drawback when changing NAMEDATALEN to 64? Put the other way
'round, what's the thinking behind having a default of 32?

That value was chosen years ago, when machines were slower and disks
smaller than today.

There's been a proposal on the table for awhile to increase the standard
NAMEDATALEN value to 64, but we haven't got round to it.

BTW, there is at least a small potential for breaking applications with
this change: NAMEDATALEN is part of the exported libpq ABI, because it
affects the representation of PGnotify structures. When and if we do
change the standard setting, I'm inclined to reverse the order of the
fields in PGnotify, so that accesses to be_pid don't depend on
NAMEDATALEN.

regards, tom lane

BTW, there is at least a small potential for breaking applications with
this change: NAMEDATALEN is part of the exported libpq ABI, because it
affects the representation of PGnotify structures. When and if we do
change the standard setting, I'm inclined to reverse the order of the
fields in PGnotify, so that accesses to be_pid don't depend on
NAMEDATALEN.

Would this also not break the method used to create SERIAL sequence names? I
know that I would have to fix a method I've written to calculate the
sequence name for a SERIAL field, and I suspect a few others have as well.
I'd be more than happy to fix it for a longer name though...

Greg

Tom Lane wrote:

Frank Joerdens <frank@joerdens.de> writes:

Is there a drawback when changing NAMEDATALEN to 64? Put the other way
'round, what's the thinking behind having a default of 32?

That value was chosen years ago, when machines were slower and disks
smaller than today.

There's been a proposal on the table for awhile to increase the standard
NAMEDATALEN value to 64, but we haven't got round to it.

BTW, there is at least a small potential for breaking applications with
this change: NAMEDATALEN is part of the exported libpq ABI, because it
affects the representation of PGnotify structures. When and if we do
change the standard setting, I'm inclined to reverse the order of the
fields in PGnotify, so that accesses to be_pid don't depend on
NAMEDATALEN.

TODO updated:

* Increase identifier length (NAMEDATALEN) if small performance hit;
change struct pgNotify to use pid first, breaks notify API

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian <pgman@candle.pha.pa.us> writes:

TODO updated:

* Increase identifier length (NAMEDATALEN) if small performance hit;
change struct pgNotify to use pid first, breaks notify API

BTW, I noticed the other day that both SQL92 and SQL99 specify the
maximum identifier length as 128. So really there is a standardization
argument for pushing it up to 128 ...

regards, tom lane

On Thursday, January 24, 2002, at 06:53 , Tom Lane wrote:

BTW, I noticed the other day that both SQL92 and SQL99 specify the
maximum identifier length as 128. So really there is a standardization
argument for pushing it up to 128 ...

Yeah, I realize this was a month ago. :)

One question: What is an identifier defined as? The reason I'm being
pendantic is that I've run into trouble not with any particular table or
column name being > 32, but the automated key name generated for tables
with a NOT NULL UNIQUE column is table_column_key, which easily busts
the limit.

The reason I ask is because if an identifier is only defined as
something like a column name or table name, then NAMEDATALEN would have
to be 128+128+5, if I did the math right.

BTW, I keep my patch for configuring it in 7.1 at:

http://www.zettabyte.net/downloads/postgres/namedatalen-patch/

in case anyone needs it.

-Bill

Bill McGonigle wrote:

On Thursday, January 24, 2002, at 06:53 , Tom Lane wrote:

BTW, I noticed the other day that both SQL92 and SQL99 specify the
maximum identifier length as 128. So really there is a standardization
argument for pushing it up to 128 ...

Yeah, I realize this was a month ago. :)

One question: What is an identifier defined as? The reason I'm being
pendantic is that I've run into trouble not with any particular table or
column name being > 32, but the automated key name generated for tables
with a NOT NULL UNIQUE column is table_column_key, which easily busts
the limit.

The reason I ask is because if an identifier is only defined as
something like a column name or table name, then NAMEDATALEN would have
to be 128+128+5, if I did the math right.

I guess we just hope then don't max out the fields as much as they do
with the 32 limit. Theoretically, yes, you could still overflow the
limit.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026