Re: Prepared Statement Name Truncation

On 18/11/12 15:46, Stephen Frost wrote:
> * Phil Sorber (phil(at)omniti(dot)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? An unfortunate
>> interaction?
> It's a bug that the ORM doesn't correctly handle this particular
> per-system limitation cleanly.
>
>> If it's a postgres bug, what is the fix? Make the identifier max size
>> longer? Set a hard limit and ERROR instead of truncating and NOTICE?
>> Both? Neither because that would break backward compatibility?
> Making the identifier longer wouldn't fix anything- an ORM might still
> think it can make identifiers longer than whatever PG is configured to
> support. Making it unlimited in length would be a huge amount of work
> without much gain, imv. ERROR'ing instead of NOTICE'ing is certainly an
> option, but it'd break any existing users of this busted ORM or other
> similar setups. That's not to say we couldn't do it, but it'd have to
> be clearly stated in the release notes and be done as part of the next
> major version of PG.
>
> For my part, being very adverse to PG possibly giving the wrong result
> (consider INSERT statements which work against a table that doesn't
> exist- because the identifier is truncated and happens to end up
> matching a table that does exist), I'd advocate changing this to be an
> ERROR in 9.3. I don't see the value in the truncation and feel it's
> actually dangerous, particularly if ORMs are doing things like this.
>
> Thanks,
>
> Stephen
+1

I hate silent errors that could potential create major problems!

It is far too MySQLish - prepares to duck and run before realizing this
is not a MySQL list! :-)

Maybe a configuration variable to allow unsafe truncation: for those
people who either have no choice, and/or prefer expediency to safety!

Cheers,
Gavin