From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [SQL] plpgsql doesn't coerce boolean expressions to |
Date: | 2003-09-28 16:02:43 |
Message-ID: | 9351.1064764963@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-sql |
Jan Wieck <JanWieck(at)Yahoo(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeroen Ruigrok/asmodai | 2003-09-28 16:05:02 | Re: _GNU_SOURCE |
Previous Message | Tom Lane | 2003-09-28 15:48:04 | Re: _GNU_SOURCE |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-09-28 16:06:22 | Re: Mystery function error |
Previous Message | Doris Bernloehr | 2003-09-28 12:43:09 | SQL Syntax problem |