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:

         if (pg_strncasecmp(value, "true", len) == 0)
                  return true;
  It happens that "" as a value yields the same result than "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


  So I've changed ParseVariableBool() in v4 to reject empty string as an
  invalid boolean (but not NULL since the startup logic requires NULL
  meaning false in the early initialization of these variables).

  "make check" seems OK with that, I hope it doesn't cause any regression

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:
Twitter: @DanielVerite

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to