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 11/19/2012 09:43 PM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Let me be clear here: I don't think we can or should ever make this
>> into an error by default. Doing that would break spec-compliant
>> applications, whether or not they are using names that actually have
>>
Stephen Frost writes:
> I'm not volunteering (yet), but I wouldn't say "no, we're never going to
> fix this" either. Perhaps a TODO item to investigate the value of
> making relname variable length? Or to investigate the actual impact of
> increasing the length?
My recollection is it's been don
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Let me be clear here: I don't think we can or should ever make this
> into an error by default. Doing that would break spec-compliant
> applications, whether or not they are using names that actually have
> any conflicts.
If we increase the length to the s
Phil Sorber writes:
> I think making this a warning now would be a bit more forceful way to
> let people know that this is a bad idea and this is a case where maybe
> they need to work around postgres' lack of conformance to the spec. It
> would most likely be caught sooner as well by DBA's. Then
On Sun, Nov 18, 2012 at 2:33 AM, Tom Lane wrote:
> Phil Sorber writes:
>> An install of ours was having an issue with log files filling up the
>> disk rather quickly. After looking into it, the log was filling up
>> with NOTICE's caused by an ORM that was using a very long identifier
>> as a name
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.
>
Phil Sorber writes:
> An install of ours was having an issue with log files filling up the
> disk rather quickly. After looking into it, the log was filling up
> with NOTICE's caused by an ORM that was using a very long identifier
> as a name for a prepared statement. It was a concatenation of tab
"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
On 18/11/12 15:46, Stephen Frost wrote:
* Phil Sorber (p...@omniti.com) wrote:
In addition it actually works!
Only until the ORM tries to create two tables that are identical except
for the last few characters..
So I am sharing this with the list to see what people think. Is this a
configurat
-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
* Phil Sorber (p...@omniti.com) wrote:
> In addition it actually works!
Only until the ORM tries to create two tables that are identical except
for the last few characters..
> So I am sharing this with the list to see what people think. Is this a
> configuration bug? An ORM bug? A postgres bug? A
An install of ours was having an issue with log files filling up the
disk rather quickly. After looking into it, the log was filling up
with NOTICE's caused by an ORM that was using a very long identifier
as a name for a prepared statement. It was a concatenation of tables
in the query. The server
22 matches
Mail list logo
