Re: [GENERAL] ON_ERROR_ROLLBACK - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: [GENERAL] ON_ERROR_ROLLBACK
Date
Msg-id 54A32647.6030709@dunslane.net
Whole thread Raw
In response to Re: [GENERAL] ON_ERROR_ROLLBACK  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [GENERAL] ON_ERROR_ROLLBACK
List pgsql-hackers
On 12/30/2014 09:20 AM, Tom Lane wrote:
> Bernd Helmle <mailings@oopsware.de> writes:
>> --On 29. Dezember 2014 12:55:11 -0500 Tom Lane <tgl@sss.pgh.pa.us> 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?
>
>             r

I got caught by this with ON_ERROR_ROLLBACK on 9.3 just this afternoon
before remembering this thread. So there's a field report :-)

+0.75 for backpatching (It's hard to imagine someone relying on the bad
behaviour, but you never know).

cheers

andrew



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [COMMITTERS] pgsql: pg_event_trigger_dropped_objects: Add name/args output columns
Next
From: Tom Lane
Date:
Subject: Re: Re: [COMMITTERS] pgsql: pg_event_trigger_dropped_objects: Add name/args output columns