On Wed, Dec 28, 2016 at 2:25 PM, Jim Nasby <jim.na...@bluetreble.com> wrote: > That's my whole point of why this needs to be settable at a global level: so > that people with a lot of legacy code can set the OLD behavior at a global > level, and deal with the old code over time.
This has the same problem being discussed nearby on the case-folding thread, though: any extension or third-party tool has to either work with every possible value, or else it has to require one particular value and therefore not be usable if you need another value for some other reason. Now, that's not to say we should never break backward compatibility. Sometimes we should. I think the problem with PL/pgsql is that many of the compatibility breaks that people want are likely to lead to subtle misbehavior rather than outright failure, or are not easy to spot via a cursory look ("hmm, could that SELECT query ever return more than one row?"). Also, while everybody agrees that a bunch of things should be changed and improved, not everybody agrees about which ones, and sometimes person A desperately wants X changed while person B desperately wants it changed in the other direction or left alone. If there were a set of changes that we could make all at once, call the result plpgsql2 or nplpgsql or whatever, and make everybody happy, that'd be fabulous, but we don't. So we're left with doing nothing, or having 2^n language variants controlled by GUCs or pragmas, neither of which is appealing. I think it would be a good idea to lock all the people who really care about PL/pgsql in a room until they agree on what changes should be made for the next version of the language. If they don't agree quickly enough, we can resort to the techniques described in https://en.wikipedia.org/wiki/Papal_election,_1268%E2%80%9371 -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers