"Daniel Verite" <daniel@manitou-mail.org> writes:
> Tom Lane wrote:
>> Evidently, this test script is relying on the preceding behavior that
>> setting a bool variable to an empty string was equivalent to setting
>> it to "true". If it's just that script I would be okay with saying
>> "well, it's a bug in that script" ... but I'm a bit worried that this
>> may be the tip of the iceberg, ie maybe a lot of people have done
>> things like this. Should we reconsider the decision to reject empty
>> strings in ParseVariableBool?
> ...
> So it does cause regressions. I don't know if we should reaccept
> empty strings immediately to fix that, but in the long run, I think
> that the above situation with the empty :AUTOCOMMIT is not really
> sustainable: when we extend what we do with variables
> (/if /endif and so on), it will become even more of a problem.
Yeah, in a green field we'd certainly not allow this, but the problem
I'm having is that in all previous versions you could do, eg,
\set ON_ERROR_STOP
... stuff expecting ON_ERROR_STOP to be on
\unset ON_ERROR_STOP
... stuff expecting ON_ERROR_STOP to be off
and it works, and looks perfectly natural, and people may well be relying
on that. Especially since the docs aren't very clear that this shouldn't
work --- psql-ref.sgml repeatedly uses phrases like "FOO is set" to
indicate that the boolean variable FOO is considered to be "on".
Moreover, the committed patch is inconsistent in that it forbids
only one of the above. Why is it okay to treat unset as "off",
but not okay to treat the default empty-string value as "on"?
Maybe it's worth breaking backwards compatibility on this point, but
I'm feeling unconvinced. This seems rather different from rejecting
clearly-wrongly-spelled values.
One possible compromise that would address your concern about display
is to modify the hook API some more so that variable hooks could actually
substitute new values. Then for example the bool-variable hooks could
effectively replace "\set AUTOCOMMIT" by "\set AUTOCOMMIT on" and
"\unset AUTOCOMMIT" by "\set AUTOCOMMIT off", ensuring that interrogation
of their values always produces sane results.
regards, tom lane