Re: Surprising behaviour of \set AUTOCOMMIT ON - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Surprising behaviour of \set AUTOCOMMIT ON
Date
Msg-id 10679.1473952228@sss.pgh.pa.us
Whole thread Raw
In response to Re: Surprising behaviour of \set AUTOCOMMIT ON  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Surprising behaviour of \set AUTOCOMMIT ON  (Robert Haas <robertmhaas@gmail.com>)
Re: Surprising behaviour of \set AUTOCOMMIT ON  ("Daniel Verite" <daniel@manitou-mail.org>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Sep 15, 2016 at 7:29 AM, Rahila Syed <rahilasyed90@gmail.com> wrote:
>> In keeping with current design of hooks instead of rejecting autocommit 'ON'
>> setting inside
>> a transaction,the value can be set to 'ON' with a psql_error displaying that
>> the value
>> will be effective when the current transaction has ended.

> Hmm, that seems like a reasonable compromise.

I dunno, implementing that seems like it will require some very fragile
behavior in the autocommit code, ie that even though the variable is "on"
we don't do anything until after reaching an out-of-transaction state.
It might work today but I'm afraid we'd break it in future.

I think changing the hook API is a pretty reasonable thing to do here
(though I'd make it its own patch and then add the autocommit change
on top).  When was the last time you actually wanted to set VERBOSITY
to "fubar"?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: select_parallel test fails with nonstandard block size
Next
From: Masahiko Sawada
Date:
Subject: Re: Vacuum: allow usage of more than 1GB of work mem