Re: Prepared Statement Name Truncation
От | Gavin Flower |
---|---|
Тема | Re: Prepared Statement Name Truncation |
Дата | |
Msg-id | 50A85EAB.8080306@archidevsys.co.nz обсуждение исходный текст |
Ответ на | Re: Prepared Statement Name Truncation ("Greg Sabino Mullane" <greg@turnstep.com>) |
Ответы |
Re: Prepared Statement Name Truncation
|
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: