Re: Prepared Statement Name Truncation

From: Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>
To: Greg Sabino Mullane <greg(at)turnstep(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org, pgsql-general(at)postgresql(dot)org
Subject: Re: Prepared Statement Name Truncation
Date: 2012-11-18 04:06:03
Message-ID: 50A85EAB.8080306@archidevsys.co.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-general

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?

Cheers,
Gavin

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Phil Sorber 2012-11-18 04:10:14 Re: Prepared Statement Name Truncation
Previous Message Gavin Flower 2012-11-18 03:54:42 Re: Prepared Statement Name Truncation

Browse pgsql-general by date

  From Date Subject
Next Message Phil Sorber 2012-11-18 04:10:14 Re: Prepared Statement Name Truncation
Previous Message Gavin Flower 2012-11-18 03:54:42 Re: Prepared Statement Name Truncation