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 <
>
>> mailings@
>
>> > writes:
>>> --On 29. Dezember 2014 12:55:11 -0500 Tom Lane <
>
>> tgl(at)(dot)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.
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
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 |
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 |