Re: [HACKERS] ON_ERROR_ROLLBACK

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

In response to

Responses

Browse pgsql-general by date

  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

Browse pgsql-hackers by date

  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