Message-ID: <3F5E0A5D.2010803@Yahoo.com>
Date: Tue, 09 Sep 2003 13:14:05 -0400
From: Jan Wieck <JanWieck@Yahoo.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org, pgsql-sql@postgresql.org
Subject: Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean
References: <15403.1063035632@sss.pgh.pa.us>
In-Reply-To: <15403.1063035632@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


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

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