On 22-11-2012 04:27, Pavel Stehule wrote:
2012/11/21 Greg Sabino Mullane g...@turnstep.com: 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 -
2012/11/23 Euler Taveira eu...@timbira.com:
On 22-11-2012 04:27, Pavel Stehule wrote:
2012/11/21 Greg Sabino Mullane g...@turnstep.com: 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
Euler Taveira eu...@timbira.com 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
On 23.11.2012 17:53, Tom Lane wrote:
Euler Taveiraeu...@timbira.com 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
Heikki Linnakangas hlinnakan...@vmware.com 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
-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
2012/11/21 Greg Sabino Mullane g...@turnstep.com:
-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
On Nov 18, 2012, at 2:24, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Sabino Mullane g...@turnstep.com 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
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 summary
-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 supports
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
On Nov 17, 2012 11:06 PM, Gavin Flower 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_identifier_for_a_prepared_statement_name_ok
will be truncated to
On 18/11/12 17:10, Phil Sorber wrote:
On Nov 17, 2012 11:06 PM, Gavin Flower
gavinflo...@archidevsys.co.nz mailto:gavinflo...@archidevsys.co.nz
wrote:
On 18/11/12 16:49, Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
NOTICE: identifier
Greg Sabino Mullane g...@turnstep.com 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
14 matches
Mail list logo
