Lists: | pgsql-general |
---|
From: | Frank Joerdens <frank(at)joerdens(dot)de> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Is there a drawback when changing NAMEDATALEN to 64? |
Date: | 2002-01-11 15:21:46 |
Message-ID: | 20020111162146.A3927@superfly.archi-me-des.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-general |
Is there a drawback when changing NAMEDATALEN to 64? Put the other way
'round, what's the thinking behind having a default of 32? The
application I am just evaluating (ezpublish from http://ez.no) requires
it.
Thanks, Frank
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Frank Joerdens <frank(at)joerdens(dot)de> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Is there a drawback when changing NAMEDATALEN to 64? |
Date: | 2002-01-11 17:11:59 |
Message-ID: | 29510.1010769119@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-general |
Frank Joerdens <frank(at)joerdens(dot)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
From: | "Gregory Wood" <gregw(at)com-stock(dot)com> |
---|---|
To: | "PostgreSQL-General" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Is there a drawback when changing NAMEDATALEN to 64? |
Date: | 2002-01-11 20:43:41 |
Message-ID: | 007f01c19ae0$a95c8810$7889ffcc@comstock.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-general |
> 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
From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Frank Joerdens <frank(at)joerdens(dot)de>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Is there a drawback when changing NAMEDATALEN to 64? |
Date: | 2002-01-24 23:49:30 |
Message-ID: | 200201242349.g0ONnUZ05345@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-general |
Tom Lane wrote:
> Frank Joerdens <frank(at)joerdens(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Frank Joerdens <frank(at)joerdens(dot)de>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Is there a drawback when changing NAMEDATALEN to 64? |
Date: | 2002-01-24 23:53:12 |
Message-ID: | 21109.1011916392@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-general |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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
From: | Bill McGonigle <mcgonigle(at)medicalmedia(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Is there a drawback when changing NAMEDATALEN to 64? |
Date: | 2002-02-26 23:25:32 |
Message-ID: | 20C2A74E-2B10-11D6-B91E-003065EAE3C0@medicalmedia.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-general |
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
From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Bill McGonigle <mcgonigle(at)medicalmedia(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Is there a drawback when changing NAMEDATALEN to 64? |
Date: | 2002-02-27 03:22:45 |
Message-ID: | 200202270322.g1R3MkC04561@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-general |
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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026