Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org, pgsql-sql(at)postgresql(dot)org
Subject: Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean
Date: 2003-09-09 17:14:05
Message-ID: 3F5E0A5D.2010803@Yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-sql

Tom Lane wrote:

> 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.

ERROR is the cleanest way, but I'd vote for conversion to boolean to
keep the damage within reason.

Jan

>
> 3. Try to convert nonbooleans to boolean using plpgsql's usual method
> for cross-type coercion, ie run the type's output proc to get a
> string and feed it to bool's input proc. (This seems unlikely to
> avoid throwing an error in very many cases, 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'd be accepted
> in a boolean-requiring SQL construct (such as CASE). (By default,
> none are, so this isn't really different from #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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-09-09 17:32:09 Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean
Previous Message Tom Lane 2003-09-09 15:54:33 Re: plpgsql doesn't coerce boolean expressions to boolean

Browse pgsql-sql by date

  From Date Subject
Next Message Tom Lane 2003-09-09 17:32:09 Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean
Previous Message Tom Lane 2003-09-09 15:54:33 Re: plpgsql doesn't coerce boolean expressions to boolean