X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [64.117.224.130]) by svr1.postgresql.org (Postfix) with ESMTP id 19192D1B513; Tue, 9 Sep 2003 16:22:48 +0000 (GMT) Received: from svr1.postgresql.org ([64.117.224.193]) by localhost (neptune.hub.org [64.117.224.130]) (amavisd-new, port 10024) with ESMTP id 29498-08; Tue, 9 Sep 2003 13:22:16 -0300 (ADT) Received: from abe.micropat.com (abe.micropat.com [204.17.221.119]) by svr1.postgresql.org (Postfix) with ESMTP id 23656D1B518; Tue, 9 Sep 2003 13:22:14 -0300 (ADT) Received: from micropat.com ([204.17.221.90]) by abe.micropat.com (Netscape Messaging Server 4.15) with ESMTP id HKYCTT00.CYM; Tue, 9 Sep 2003 11:10:41 -0400 Message-ID: <3F5DF15C.EAB56AA6@micropat.com> Date: Tue, 09 Sep 2003 11:27:24 -0400 From: "Richard Hall" Organization: Micropatent, LLC X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom Lane Cc: pgsql-hackers@postgresql.org, pgsql-sql@postgresql.org Subject: Re: plpgsql doesn't coerce boolean expressions to boolean References: <15403.1063035632@sss.pgh.pa.us> Content-Type: multipart/alternative; boundary="------------964168F668464A67BDCB5E17" X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200309/64 X-Sequence-Number: 15042 --------------964168F668464A67BDCB5E17 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Define the language! If it breaks code, so be it. 2. Throw an error if the expression doesn't return boolean. Yes, yes, absolutely. By definition "an IF, WHILE, or EXIT statement is a boolean expression" SO if "some stupid piece of text" THEN should not compile, there is no BOOLEAN expression. C's implementation of hat is true and false has always, IMHO, been hideous. But then again, I am a Pascal kind of thinker. An integer with a value of 1 is still only an integer, IF I <> 0 THEN ... is clear and un-ambiguous. 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 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly --------------964168F668464A67BDCB5E17 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Define the language! If it breaks code, so be it.

2. Throw an error if the expression doesn't return boolean.
Yes, yes, absolutely.

By definition "an IF, WHILE, or EXIT statement is a boolean expression"
SO
    if "some stupid piece of text" THEN
should not compile, there is no BOOLEAN expression.

C's implementation of hat is true and false has always, IMHO, been hideous. But then again, I am a Pascal kind of thinker.
An integer with a value of 1 is still only an integer,
    IF I <> 0 THEN ...
is clear and un-ambiguous.
 
 

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 3: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to majordomo@postgresql.org so that your
      message can get through to the mailing list cleanly

--------------964168F668464A67BDCB5E17--