Andrew Dunstan writes:
> On 12/30/2014 09:20 AM, Tom Lane wrote:
>> 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 count
On 12/30/2014 09:20 AM, Tom Lane wrote:
Bernd Helmle writes:
--On 29. Dezember 2014 12:55:11 -0500 Tom Lane 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 r
On Tue, Dec 30, 2014 at 8:54 AM, Adrian Klaver
wrote:
> 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@.pa
>>>
>>
>> > wrote:
>>>
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@.pa
> wrote:
Given the lack of previous complaints, this probably isn't backpatching
material, but it sure seems like a bit of at
Tom Lane-2 wrote
> Bernd Helmle <
> mailings@
> > writes:
>> --On 29. Dezember 2014 12:55:11 -0500 Tom Lane <
> tgl@.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 warr
Bernd Helmle writes:
> --On 29. Dezember 2014 12:55:11 -0500 Tom Lane 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 compl
--On 29. Dezember 2014 12:55:11 -0500 Tom Lane 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
On 12/29/2014 09:55 AM, Tom Lane wrote:
Adrian Klaver writes:
So it seems you can turn ON_ERROR_ROLLBACK on with either 1 or 'on', but you
can only turn it off with 'off'.
With ON_ERROR_STOP 1/on and 0/off both seem to work.
Is this expected?
Given the lack of previous complaints, thi
Adrian Klaver writes:
> So it seems you can turn ON_ERROR_ROLLBACK on with either 1 or 'on', but you
> can only turn it off with 'off'.
> With ON_ERROR_STOP 1/on and 0/off both seem to work.
> Is this expected?
on_error_stop_hook() uses ParseVariableBool, while
on_error_rollback_hook() uses so
On 12/29/2014 08:51 AM, Adrian Klaver wrote:
While working on the thread 'Rollback on include error in psql' I ran across
something I am not sure with regards to ON_ERROR_ROLLBACK:
So it seems you can turn ON_ERROR_ROLLBACK on with either 1 or 'on', but you
can only turn it off with 'off'.
While working on the thread 'Rollback on include error in psql' I ran across
something I am not sure with regards to ON_ERROR_ROLLBACK:
aklaver@panda:~> psql -d test -U aklaver -p 5452 --single-transaction --set
ON_ERROR_STOP=on --set AUTOCOMMIT=off -f test_script.sql
UPDATE 1
psql:test_script
11 matches
Mail list logo