Thread: psql \set case sensitive for boolean (OFF/off)

psql is currently case sensitive for boolean values in \set, only "off" is
regarded as off, whereas "OFF" is regarded as on.

There is a comment in the code that explains, why other values than "off"
are always treated as true:
"for backwards compatibility, anything except "off" is taken as "true"

I would recommend to make this check at least case insensitive, because

a) Since SQL is case insensitive, the current behaviour is not what you
would expect.

b) I have stumbled over this myself (setting AUTOCOMMIT to 'OFF' and then
having problems because it was on)

c) I think there are other who were/will be bitten by this (recommendation
on general to use --set AUTOCOMMIT=OFF...)


I would change strcmp to strcasecmp in GetVariableBool in variable.c. For
the other functions (VariableEquals e.g.) I cannot speak, since I don't know
if the case sensitivity is needed.

Patch attached. Is strcasecmp ok, or should pg_strcasecmp be used here?

Best Regards,
Michael Paesold

I wrote:
> Patch attached. Is strcasecmp ok, or should pg_strcasecmp be used here?

I don't know how I did it, but this was the wrong patch. Correct patch
attached now.

Best Regards,
MIchael Paesold

Am Dienstag, 21. September 2004 13:01 schrieb Michael Paesold:
> I would recommend to make this check at least case insensitive, because
>
> a) Since SQL is case insensitive, the current behaviour is not what you
> would expect.

In contrast, psql is case sensitive, so the current behavior is consistent.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut <peter_e@gmx.net> writes:
> Am Dienstag, 21. September 2004 13:01 schrieb Michael Paesold:
>> I would recommend to make this check at least case insensitive, because
>>
>> a) Since SQL is case insensitive, the current behaviour is not what you
>> would expect.

> In contrast, psql is case sensitive, so the current behavior is consistent.

True, but recognizing "off" case-insensitively seems like a painless
improvement.  What would it be likely to get wrong?  (I've forgotten
what the original backwards-compatibility issue alluded to in the
comment was all about, so maybe I'm missing something important.)

If anything I'd think we should migrate towards allowing all the same
alternatives that backend GUC accepts for booleans ...

            regards, tom lane

Patch applied.  Thanks.

---------------------------------------------------------------------------


Michael Paesold wrote:
> I wrote:
> > Patch attached. Is strcasecmp ok, or should pg_strcasecmp be used here?
>
> I don't know how I did it, but this was the wrong patch. Correct patch
> attached now.
>
> Best Regards,
> MIchael Paesold

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
>       joining column's datatypes do not match

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073