Re: [GENERAL] [BUGS] Prepared Statement Name Truncation

2012-11-23 Thread Tom Lane
Heikki Linnakangas writes: > On 23.11.2012 17:53, Tom Lane wrote: >> We could avoid this problem if we were prepared to make type "name" >> be varlena, ... > It would actually be nice to do that because it would *reduce* the > amount of space and memory used for the catalogs in the typical case

Re: [GENERAL] [BUGS] Prepared Statement Name Truncation

2012-11-23 Thread Heikki Linnakangas
On 23.11.2012 17:53, Tom Lane wrote: Euler Taveira writes: On 22-11-2012 04:27, Pavel Stehule wrote: significantly larger catalog Less than 5% of catalog columns? I don't buy your argument. It's not about count, it's about size. For instance, pg_attribute currently requires 140 bytes per

Re: [GENERAL] [BUGS] Prepared Statement Name Truncation

2012-11-23 Thread Tom Lane
Euler Taveira writes: > On 22-11-2012 04:27, Pavel Stehule wrote: >>> significantly larger catalog > Less than 5% of catalog columns? I don't buy your argument. It's not about count, it's about size. For instance, pg_attribute currently requires 140 bytes per row (counting the tuple header and

Re: [GENERAL] [BUGS] Prepared Statement Name Truncation

2012-11-18 Thread David Johnston
On Nov 18, 2012, at 2:24, Tom Lane wrote: > "Greg Sabino Mullane" writes: >>> If it's a postgres bug, what is the fix? Make the identifier max size >>> longer? > >> I'd also be in favor of this, in addition to upgrading from a NOTICE. > > On the whole I'm not too excited about changing this. >

Re: [GENERAL] [BUGS] Prepared Statement Name Truncation

2012-11-17 Thread Tom Lane
"Greg Sabino Mullane" writes: >> If it's a postgres bug, what is the fix? Make the identifier max size >> longer? > I'd also be in favor of this, in addition to upgrading from a NOTICE. Increasing NAMEDATALEN has been discussed, and rejected, before. It is very very far from being a free change