On 18/11/12 17:10, Phil Sorber wrote:
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.
[...]
>>> 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.
[...]
How about a WARNING in 9.2.2, and ERROR in 9.3 with a configuration
option to downgrade it to WARNING - as well as increasing the max
length to 128 to match the standard in 9.3 (I assume the size
increase is to drastic for 9.2.x!)?
Cheers,
Gavin
|