Re: Prepared Statement Name Truncation
От | Gavin Flower |
---|---|
Тема | Re: Prepared Statement Name Truncation |
Дата | |
Msg-id | 50A85C02.5030309@archidevsys.co.nz обсуждение исходный текст |
Ответ на | Re: Prepared Statement Name Truncation (Stephen Frost <sfrost@snowman.net>) |
Список | pgsql-bugs |
On 18/11/12 15:46, Stephen Frost wrote: > * Phil Sorber (phil@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? 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
В списке pgsql-bugs по дате отправления: