plpgsql doesn't coerce boolean expressions to boolean - Mailing list pgsql-hackers

From Tom Lane
Subject plpgsql doesn't coerce boolean expressions to boolean
Date
Msg-id 15403.1063035632@sss.pgh.pa.us
Whole thread Raw
Responses Re: plpgsql doesn't coerce boolean expressions to boolean  (Andrew Dunstan <andrew@dunslane.net>)
Re: plpgsql doesn't coerce boolean expressions to boolean  (Andreas Pflug <pgadmin@pse-consulting.de>)
Re: [SQL] plpgsql doesn't coerce boolean expressions to boolean  (Manfred Koizar <mkoi-pg@aon.at>)
Re: plpgsql doesn't coerce boolean expressions to boolean  (Jan Wieck <JanWieck@Yahoo.com>)
Re: [SQL] plpgsql doesn't coerce boolean expressions to boolean  ("R. van Twisk" <r.vantwisk@jongert.nl>)
Re: plpgsql doesn't coerce boolean expressions to boolean  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Following up this gripe
http://archives.postgresql.org/pgsql-sql/2003-09/msg00044.php
I've realized that plpgsql just assumes that the test expression
of an IF, WHILE, or EXIT statement is a boolean expression.  It
doesn't take any measures to ensure this is the case or convert
the value if it's not the case.  This seems pretty bogus to me.

However ... with the code as it stands, for pass-by-reference datatypes
any nonnull value will appear TRUE, while for pass-by-value datatypes
any nonzero value will appear TRUE.  I fear that people may actually be
depending on these behaviors, particularly the latter one which is
pretty reasonable if you're accustomed to C.  So while I'd like to throw
an error if the argument isn't boolean, I'm afraid of breaking people's
function definitions.

Here are some possible responses, roughly in order of difficulty
to implement:

1. Leave well enough alone (and perhaps document the behavior).

2. Throw an error if the expression doesn't return boolean.

3. Try to convert nonbooleans to boolean using plpgsql's usual method  for cross-type coercion, ie run the type's
outputproc to get a  string and feed it to bool's input proc.  (This seems unlikely to  avoid throwing an error in very
manycases, but it'd be the most  consistent with other parts of plpgsql.)
 

4. Use the parser's coerce_to_boolean procedure, so that nonbooleans  will be accepted in exactly the same cases where
they'dbe accepted  in a boolean-requiring SQL construct (such as CASE).  (By default,  none are, so this isn't really
differentfrom #2.  But people could  create casts to boolean to override this behavior in a controlled  fashion.)
 

Any opinions about what to do?
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Gaetano Mendola"
Date:
Subject: Re: mcxt.c
Next
From: Richard Huxton
Date:
Subject: Re: plpgsql debugging