On Nov 17, 2012 11:06 PM, "Gavin Flower" <gavinflo...@archidevsys.co.nz> 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. >> >>> 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? >
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. > > Cheers, > Gavin > > > > > > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs
