Re: Surprising behaviour of \set AUTOCOMMIT ON

On Thu, Sep 15, 2016 at 11:10 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Thu, Sep 15, 2016 at 7:29 AM, Rahila Syed <rahilasyed90(at)gmail(dot)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.

Hmm, I don't think any logic change is being proposed, just a warning
that it may not work the way you think. So I don't think it would be
any more fragile than now. Am I missing something?

> 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"?

I agree that'd be better but I don't know that we should expect Rahila
to do that as a condition of getting a usability warning accepted.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company