Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org, pgsql-sql(at)postgresql(dot)org
Subject: Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean
Date: 2003-09-26 22:47:47
Message-ID: 200309262247.h8QMllm12659@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-sql


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(at)postgresql(dot)org)
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2003-09-26 22:49:08 Re: ISO 8601 'Time Intervals' of the 'format with time-unit
Previous Message Bruce Momjian 2003-09-26 22:34:10 Re: initdb failure (was Re: [GENERAL] sequence's plpgsql)

Browse pgsql-sql by date

  From Date Subject
Next Message Tom Lane 2003-09-26 22:53:06 Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean
Previous Message Christopher Browne 2003-09-26 20:28:23 Re: does postgresql execute unions in parallel?