On Mon, Mar 25, 2013 at 5:14 PM, Josh Berkus <josh@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
