Re: Surprising behaviour of \set AUTOCOMMIT ON - Mailing list pgsql-hackers
| From | Rahila Syed |
|---|---|
| Subject | Re: Surprising behaviour of \set AUTOCOMMIT ON |
| Date | |
| Msg-id | CAH2L28tq3ragdy0_v8dTLqx9otA_ix+PddR=NybB8F=4n7SChw@mail.gmail.com Whole thread Raw |
| In response to | Re: Surprising behaviour of \set AUTOCOMMIT ON (Tom Lane <tgl@sss.pgh.pa.us>) |
| Responses |
Re: Surprising behaviour of \set AUTOCOMMIT ON
(Robert Haas <robertmhaas@gmail.com>)
|
| List | pgsql-hackers |
>Have you considered expanding
>the API for hook functions?
>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.
>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@sss.pgh.pa.us> wrote:
Rahila Syed <rahilasyed90@gmail.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
pgsql-hackers by date: