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
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
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
2012/11/23 Euler Taveira :
> On 22-11-2012 04:27, Pavel Stehule wrote:
>> 2012/11/21 Greg Sabino Mullane : Separately, what are
>> the objections to raising the size limit to 128?
>>
>>> significantly larger catalog
>>
> Less than 5% of catalog columns? I don't buy your argument.
default 6201kB (6
On 22-11-2012 04:27, Pavel Stehule wrote:
> 2012/11/21 Greg Sabino Mullane : Separately, what are
> the objections to raising the size limit to 128?
>
>> significantly larger catalog
>
Less than 5% of catalog columns? I don't buy your argument.
--
Euler Taveira de Oliveira - Timbira h
2012/11/21 Greg Sabino Mullane :
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
> Gavin Flower asks:
>
>> Would it be appropriate to make it a WARNING in 9.2.2, then
>> increase the length in 9.3?
>
> No: revisions are reserved for bug fixes. This would be more of
> a behavior fix and a
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Gavin Flower asks:
> Would it be appropriate to make it a WARNING in 9.2.2, then
> increase the length in 9.3?
No: revisions are reserved for bug fixes. This would be more of
a behavior fix and as such would go into a major version.
Gavan Sc
On Sunday, November 18, 2012 at 01:10, David Johnston wrote:
>
> Can the system be made smart enough to not allow intra-schema
> collisions in addition to same schema ones? That would seem to be the
> area of greatest concern - particularly around the usage of
> truncate/delete/drop.
>
>
My su
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.
>
"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
On 18/11/12 17:10, Phil Sorber wrote:
On Nov 17, 2012 11:06 PM, "Gavin Flower"
mailto:gavinflo...@archidevsys.co.nz>>
wrote:
>
> On 18/11/12 16:49, Greg Sabino Mullane wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: RIPEMD160
>>
>>
>>> NOTICE: identifier
>>> "this_is_a_really_long_i
On Nov 17, 2012 11:06 PM, "Gavin Flower"
wrote:
>
> On 18/11/12 16:49, Greg Sabino Mullane wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: RIPEMD160
>>
>>
>>> NOTICE: identifier
>>> "this_is_a_really_long_identifier_for_a_prepared_statement_name_ok"
>>> will be truncated to
>>> "this_is_
On 18/11/12 16:49, Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
NOTICE: identifier
"this_is_a_really_long_identifier_for_a_prepared_statement_name_ok"
will be truncated to
"this_is_a_really_long_identifier_for_a_prepared_statement_name_"
PREPARE
...
The ORM
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> NOTICE: identifier
> "this_is_a_really_long_identifier_for_a_prepared_statement_name_ok"
> will be truncated to
> "this_is_a_really_long_identifier_for_a_prepared_statement_name_"
> PREPARE
...
> The ORM could use a shorter identifier, but it
14 matches
Mail list logo