On 12/30/2014 07:43 AM, David G Johnston wrote:
Tom Lane-2 wrote
Bernd Helmle <
mailings@
> writes:
--On 29. Dezember 2014 12:55:11 -0500 Tom Lane <
tgl@.pa
> wrote:
Given the lack of previous complaints, this probably isn't backpatching
material, but it sure seems like a bit of attention to consistency
would be warranted here.
Now that i read it i remember a client complaining about this some time
ago. I forgot about it, but i think there's value in it to backpatch.
Hm. Last night I wrote the attached draft patch, which I was intending
to apply to HEAD only. The argument against back-patching is basically
that this might change the interpretation of scripts that had been
accepted silently before. For example
\set ECHO_HIDDEN NoExec
will now select "noexec" mode whereas before you silently got "on" mode.
In one light this is certainly a bug fix, but in another it's just
definitional instability.
If we'd gotten a field bug report we might well have chosen to back-patch,
though, and perhaps your client's complaint counts as that.
Opinions anyone?
-0.5 for back patching
The one thing supporting this is that we'd potentially be fixing scripts
that are broken but don't know it yet. But the downside of changing active
settings for working scripts - even if they are only accidentally working -
is enough to counter that for me. Being more liberal in our acceptance of
input is more feature than bug fix even if we document that we accept more
items.
It is more about being consistent then liberal. Personally I think a situation where for one variable 0 = off but for another 0 = on, is a bug
I can sorta buy the consistency angle but what will seal it for me is script portability - the ability to write a script and instructions using the most current release and have it run on previous versions without having to worry about this kind of incompatibility.
So, +1 for back patching from me.
David J.
