On Mon, Mar 25, 2013 at 5:14 PM, Josh Berkus <j...@agliodbs.com> wrote: > Tom, > >> No, it *isn't* a good idea. GUCs that change application-visible >> semantics are dangerous. We should have learned this lesson by now. > > Really? I thought that standard_conforming_strings was a great example > of how to ease our users into a backwards-compatibility break.
It is, but it was made in full knowledge of the risks and costs. What do you do if you're given two modules that have opposite expectations for this variable? One module or the other might have hidden unexpected bugs or even security holes if the variable is set in a way it doesn't expect. You have to pick one value for the whole database. I'm not as sanguine as Tom is about how likely these corner cases will be met actually. As far as I can tell checking IS NULL on array_length() was the supported way to check for 0-length arrays previously so I suspect a lot of applications will need to be updated. But it's not a hard update to do and is the kind of update that's often needed on major database upgrades. At least if it's a clean break then everyone on 9.3 knows they need to do IS NULL and everyone on 9.4 knows they need to check for 0. If there's a GUC then people need to code defensively without knowing which semantics they'll get. And if they test they need to test twice under both settings just in case the user's database has the other setting. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
