From: Bruce Momjian <pgman@candle.pha.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Cc: pgsql-sql@postgresql.org
Subject: Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean
Date: Fri, 26 Sep 2003 18:47:47 -0400 (EDT)
Message-ID: <200309262247.h8QMllm12659@candle.pha.pa.us> (raw)
In-Reply-To: <15403.1063035632@sss.pgh.pa.us>
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@postgresql.org)
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: pgman@candle.pha.pa.us, tgl@sss.pgh.pa.us, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean
In-Reply-To: <200309262247.h8QMllm12659@candle.pha.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox