On Nov 17, 2012 11:06 PM, "Gavin Flower" <GavinFlower@xxxxxxxxxxxxxxxxx> 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_a_really_long_identifier_for_a_prepared_statement_name_"
>>> PREPARE
>>
>> ...
>>>
>>> The ORM could use a shorter identifier, but it supports multiple backends
>>> and this is probably not something in their test suite. In addition it
>>> actually works!
>>
>> For now. If it really works, then by definition it does not /need/ to
>> be that long, as the truncated version is not blowing things up.
>>
>>> So I am sharing this with the list to see what people think. Is this a
>>> configuration bug? An ORM bug? A postgres bug? An unfortunate
>>> interaction?
>>
>> Part ORM fault, part Postgres. We really should be throwing something
>> stronger than a NOTICE on such a radical change to what the user
>> asked for. I'd lobby for WARNING instead of ERROR, but either way, one
>> could argue that applications would be more likely to notice and
>> fix themselves if it was stronger than a NOTICE.
>>
>>> 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. We
>> no longer have any technical reason to keep it NAMEDATALEN, with
>> the listen/notify rewrite, correct? If so, I'd like to see the max bumped
>> to at least 128 to match the default SQL spec length for similar items.
>>
>>> Set a hard limit and ERROR instead of truncating and NOTICE?
>>> Both? Neither because that would break backward compatibility?
>>
>> My vote is WARNING and bump limit to 128 in 9.3. That's the combo most
>> likely to make dumb applications work better while not breaking
>> existing smart ones.
>>
>>
>> [...]
>>
> Would it be appropriate to make it a WARNING in 9.2.2, then increase the length in 9.3?
>
> Though I still feel I'd like it to be an ERROR, may be a configuration variable in 9.3 to promote it to an ERROR with WARNING being the default?
>
In that case I'd make it ERROR by default and make people override to WARNING if it breaks things. Otherwise no one will change.
>
> Cheers,
> Gavin
>
>
>
>
>
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@xxxxxxxxxxxxxx)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
