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>