From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bernd Helmle <mailings(at)oopsware(dot)de> |
Cc: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] ON_ERROR_ROLLBACK |
Date: | 2014-12-30 22:25:11 |
Message-ID: | 54A32647.6030709@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On 12/30/2014 09:20 AM, Tom Lane wrote:
> Bernd Helmle <mailings(at)oopsware(dot)de> writes:
>> --On 29. Dezember 2014 12:55:11 -0500 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Pawel Veselov | 2014-12-31 00:10:20 | Re: Improving performance of merging data between tables |
Previous Message | Andres Freund | 2014-12-30 17:56:47 | Re: bdr_init_copy fails when starting 2nd BDR node |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-12-30 22:27:26 | Re: Re: [COMMITTERS] pgsql: pg_event_trigger_dropped_objects: Add name/args output columns |
Previous Message | Alvaro Herrera | 2014-12-30 22:16:38 | Re: [COMMITTERS] pgsql: pg_event_trigger_dropped_objects: Add name/args output columns |