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?
Sigh. It was considered upthread, I'm requoting the relevant bit:
<quote> if (pg_strncasecmp(value, "true", len) == 0) return true; It happens that "" as a value yields the same
resultthan "true" for this test so it passes, but it seems rather unintentional.
The resulting problem from the POV of the user is that we can do that, for instance:
test=> \set AUTOCOMMIT
without error message or feedback, and that leaves us without much clue about autocommit being enabled:
test=> \echo :AUTOCOMMIT
test=>
So I've changed ParseVariableBool() in v4 to reject empty string as an invalid boolean (but not NULL since the startup
logicrequires NULL meaning false in the early initialization of these variables).
"make check" seems OK with that, I hope it doesn't cause any regression elsewhere.
</quote>
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.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite