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 4695.1473961140@sss.pgh.pa.us
Whole thread Raw
In response to Re: Surprising behaviour of \set AUTOCOMMIT ON  ("Daniel Verite" <daniel@manitou-mail.org>)
List pgsql-hackers
"Daniel Verite" <daniel@manitou-mail.org> writes:
> It looks easy to make the hooks return a bool, and when returning false,
> cancel the assignment of the variable.

Yeah, that's about how I was envisioning it too.

> I volunteer to write that patch.

Thanks.

> It would close the hazard that exists today of an internal psql flag
> getting decorrelated from the corresponding variable, due to feeding
> it with a wrong value, or in the case of autocommit, in the wrong
> context.

If we want to get to the situation that the variable's value always
reflects the internal state, then we should reject deleting the variable
too.  Currently that's allowed; I was unsure whether we should still
permit it, but this line of thought says no.

Another issue is what to do in SetVariableAssignHook().  Currently,
that's only invoked immediately after creating the variable space
so it will always go through the hook(NULL) call, which the hook
will think means deletion and then fail for, given the above change.

What might be cleanest is to modify SetVariableAssignHook so that it
is passed both the initial value and the hook (deleting the separate
initial-value-setting calls that currently exist near startup.c:40).
If the hook rejects the initial value, that would be grounds for
fatal exit.

> Also with that, the behavior of ParseVariableBool() assuming "on"
> when it's being fed with junk could be changed.

Right.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: [COMMITTERS] pgsql: Support OpenSSL 1.1.0.
Next
From: Robert Haas
Date:
Subject: Re: LOCK TABLE .. DEFERRABLE