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. That said it may be worth a documentation change and release note
that those options are not liberal currently so as to help those relying on
issues find and fix them proactively.
David J.
--
View this message in context: http://postgresql.nabble.com/ON-ERROR-ROLLBACK-tp5832298p5832448.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.