From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200309262247.h8QMllm12659@candle.pha.pa.us>
Subject: Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean
In-Reply-To: <15403.1063035632@sss.pgh.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Fri, 26 Sep 2003 18:47:47 -0400 (EDT)
Cc: pgsql-hackers@postgresql.org, pgsql-sql@postgresql.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII


Where are we on this --- we all decided on #4.  Does this just require
an announcment in the release notes.

(I need to complete the release notes soon.)

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

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.
> 
> 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@postgresql.org)
> 

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