To: Jan Wieck <JanWieck@Yahoo.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [SQL] plpgsql doesn't coerce boolean expressions to 
In-reply-to: <3F765672.2020304@Yahoo.com> 
References: <15403.1063035632@sss.pgh.pa.us> <3F5E0A5D.2010803@Yahoo.com>
	<3559.1063128729@sss.pgh.pa.us> <3F5E84CF.6090706@Yahoo.com>
	<3487.1064712513@sss.pgh.pa.us> <3F765672.2020304@Yahoo.com>
Comments: In-reply-to Jan Wieck <JanWieck@Yahoo.com>
	message dated "Sat, 27 Sep 2003 23:33:06 -0400"
Date: Sun, 28 Sep 2003 12:02:43 -0400
Message-ID: <9351.1064764963@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Jan Wieck <JanWieck@Yahoo.com> writes:
> Tom Lane wrote:
>> if count(*) = 0 from Room where roomno = new.roomno then
>> raise exception ''Room % does not exist'', new.roomno;
>> end if;
>> 
>> Is this really intended to be a feature?

> I have to admit it was less an intention than more a side effect of the 
> actual implementation. It was so easy to simply stick "SELECT " in front 
> of "everything between IF and THEN" and expect the result to be a boolean.

Sure, it was easy given a certain implementation technique.  Question
is, do we want to consider it a supported feature even if it makes the
implementation hard?

> In the same way you can do
>      varname := count(*) from Room where roomno = new.roomno;

This actually doesn't bother me; I see it as simply a variant syntax
for SELECT INTO.  (Perhaps it should be documented that way.)

If we want to preserve this behavior for IF et al, I don't think there
is any practical way to apply SQL-level type coercion as I had wanted.
We could instead make the code act like it's assigning to a plpgsql
boolean variable --- but it will apply plpgsql's textual conversion
methods, not SQL type coercion.

			regards, tom lane