--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.
