Re: [HACKERS] ON_ERROR_ROLLBACK

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: [HACKERS] ON_ERROR_ROLLBACK
Date: 2014-12-30 15:54:04
Message-ID: 54A2CA9C.2070604@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On 12/30/2014 07:43 AM, David G Johnston wrote:
> Tom Lane-2 wrote
>> Bernd Helmle &lt;
>
>> mailings@
>
>> &gt; writes:
>>> --On 29. Dezember 2014 12:55:11 -0500 Tom Lane &lt;
>
>> tgl(at)(dot)pa
>
>> &gt; 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

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

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message David Johnston 2014-12-30 16:21:39 Re: [HACKERS] ON_ERROR_ROLLBACK
Previous Message David G Johnston 2014-12-30 15:43:01 Re: [HACKERS] ON_ERROR_ROLLBACK

Browse pgsql-hackers by date

  From Date Subject
Next Message Abhijit Menon-Sen 2014-12-30 16:06:19 Re: What exactly is our CRC algorithm?
Previous Message Greg Sabino Mullane 2014-12-30 15:43:12 Re: Detecting backend failures via libpq / DBD::Pg