Re: Surprising behaviour of \set AUTOCOMMIT ON

"Daniel Verite" <daniel(at)manitou-mail(dot)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