Re: plpgsql doesn't coerce boolean expressions to boolean

Define the language! If it breaks code, so be it. <p><b>2. Throw an error if the expression doesn't return
boolean.</b><br/>Yes, yes, absolutely. <p>By definition "an IF, WHILE, or EXIT statement is a boolean expression" <br
/>SO<br />    if "some stupid piece of text" THEN <br />should not compile, there is no BOOLEAN expression. <p>C's
implementationof hat is true and false has always, IMHO, been hideous. But then again, I am a Pascal kind of thinker.
<br/>An integer with a value of 1 is still only an integer, <br />    IF I <> 0 THEN ... <br />is clear and
un-ambiguous.<br />  <br />  <p>Tom Lane wrote: <blockquote type="CITE">Following up this gripe <br /><a
href="http://archives.postgresql.org/pgsql-sql/2003-09/msg00044.php">http://archives.postgresql.org/pgsql-sql/2003-09/msg00044.php</a><br
/>I'verealized that plpgsql just assumes that the test expression <br />of an IF, WHILE, or EXIT statement is a boolean
expression. It <br />doesn't take any measures to ensure this is the case or convert <br />the value if it's not the
case. This seems pretty bogus to me. <p>However ... with the code as it stands, for pass-by-reference datatypes <br
/>anynonnull value will appear TRUE, while for pass-by-value datatypes <br />any nonzero value will appear TRUE.  I
fearthat people may actually be <br />depending on these behaviors, particularly the latter one which is <br />pretty
reasonableif you're accustomed to C.  So while I'd like to throw <br />an error if the argument isn't boolean, I'm
afraidof breaking people's <br />function definitions. <p>Here are some possible responses, roughly in order of
difficulty<br />to implement: <p>1. Leave well enough alone (and perhaps document the behavior). <p>2. Throw an error
ifthe expression doesn't return boolean. <p>3. Try to convert nonbooleans to boolean using plpgsql's usual method <br
/>  for cross-type coercion, ie run the type's output proc to get a <br />   string and feed it to bool's input proc. 
(Thisseems unlikely to <br />   avoid throwing an error in very many cases, but it'd be the most <br />   consistent
withother parts of plpgsql.) <p>4. Use the parser's coerce_to_boolean procedure, so that nonbooleans <br />   will be
acceptedin exactly the same cases where they'd be accepted <br />   in a boolean-requiring SQL construct (such as
CASE). (By default, <br />   none are, so this isn't really different from #2.  But people could <br />   create casts
toboolean to override this behavior in a controlled <br />   fashion.) <p>Any opinions about what to do?
<p>                       regards, tom lane <p>---------------------------(end of broadcast)---------------------------
<br/>TIP 3: if posting/reading through Usenet, please send an appropriate <br />      subscribe-nomail command to
majordomo@postgresql.orgso that your <br />      message can get through to the mailing list cleanly</blockquote>