Re: Surprising behaviour of \set AUTOCOMMIT ON

>Have you considered expanding
>the API for hook functions?

Changing the hooks API to allow rejecting a setting and return false is
certainly useful
to other psql variables wanting to report an error and reject a value.

I did not consider expanding hook APIs because there was no requirement in
sight for other
variables to reject a setting. As far as autocommit is concerned something
in line with the current design can be implemented.

In the current design, any unrecognisable/bad value is reinterpreted and
the execution inside hook is always
successful.
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.

>Actually, it would make a lot more sense UI-wise if attempting to assign a
>non-boolean value to a boolean variable resulted in an error and no change
>to the variable, instead of what happens now.
Hooks API can be expanded to implement this.

The proposed feature is mainly to reduce the ambiguity for the user when
\set AUTOCOMMIT on is run within a transaction. According to current
behaviour,
the variable is set immediately but it is effective only when the current
transaction
has ended. It is good to notify this to the user.
This ambiguity in the behaviour was highlighted because in AUTOCOMMIT off
mode Postgres
implicitly starts a transaction and behaviour of \set AUTOCOMMIT ON in such
scenario can
be confusing.

Thank you,
Rahila Syed

On Wed, Sep 14, 2016 at 8:06 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Rahila Syed <rahilasyed90(at)gmail(dot)com> writes:
> >> Looking at the other variables hooks, they already emit errors and can
> >> deny the effect of a change corresponding to a new value, without
> >> informing the caller. Why would autocommit be different?
>
> > These instances where psql_error occurs inside hooks the command is
> > successful and the value supplied by user is reinterpreted to some other
> > value as user had supplied an unrecognisable value.
> > With psql_error_on_autocommit patch what was intended was to make
> > the command unsuccessful and keep the previous setting of autocommit.
> > Hence having it inside autocommit_hook did not seem appropriate to me.
>
> Nonetheless, asking all callers of SetVariable to deal with such cases
> is entirely unmaintainable/unacceptable. Have you considered expanding
> the API for hook functions? I'm not really sure why we didn't provide a
> way for the hooks to reject a setting to begin with.
>
> Actually, it would make a lot more sense UI-wise if attempting to assign a
> non-boolean value to a boolean variable resulted in an error and no change
> to the variable, instead of what happens now.
>
> Anyway, I'm not very thrilled with the idea that AUTOCOMMIT is so special
> that it should have a different behavior than any other built-in psql
> variable. If we make them all throw errors and refuse to change to bad
> values, that would be consistent and defensible IMO. But having
> AUTOCOMMIT alone act that way is not a feature, it's a wart.
>
> regards, tom lane
>