To: Jan Wieck <JanWieck@Yahoo.com>
Cc: pgsql-hackers@postgresql.org, pgsql-sql@postgresql.org
Subject: Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean 
In-reply-to: <3F5E0A5D.2010803@Yahoo.com> 
References: <15403.1063035632@sss.pgh.pa.us> <3F5E0A5D.2010803@Yahoo.com>
Comments: In-reply-to Jan Wieck <JanWieck@Yahoo.com>
	message dated "Tue, 09 Sep 2003 13:14:05 -0400"
Date: Tue, 09 Sep 2003 13:32:09 -0400
Message-ID: <3559.1063128729@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Jan Wieck <JanWieck@Yahoo.com> writes:
> ERROR is the cleanest way, but I'd vote for conversion to boolean to 
> keep the damage within reason.

Which style of conversion did you like?  These were the choices:

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

At this point I'm kinda leaning to #4, because (for example) people
could create a cast from integer to boolean to avoid having to fix their
plpgsql functions right away.  #3 would not offer any configurability of
behavior.

			regards, tom lane