X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [64.117.224.130]) by svr1.postgresql.org (Postfix) with ESMTP id 12AE2D1B4F8 for ; Mon, 8 Sep 2003 16:21:04 +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 78305-04 for ; Mon, 8 Sep 2003 13:20:53 -0300 (ADT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.184]) by svr1.postgresql.org (Postfix) with ESMTP id 23D70D1B528 for ; Mon, 8 Sep 2003 13:20:53 -0300 (ADT) Received: from [212.227.126.161] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 19wOl1-0003kZ-00; Mon, 08 Sep 2003 18:20:51 +0200 Received: from [80.129.141.206] (helo=pse-consulting.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 19wOl0-0006gP-00; Mon, 08 Sep 2003 18:20:50 +0200 Message-ID: <3F5CAC68.30502@pse-consulting.de> Date: Mon, 08 Sep 2003 18:20:56 +0200 From: Andreas Pflug User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Lane Cc: pgsql-hackers@postgreSQL.org Subject: Re: plpgsql doesn't coerce boolean expressions to boolean References: <15403.1063035632@sss.pgh.pa.us> In-Reply-To: <15403.1063035632@sss.pgh.pa.us> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postgresql.org X-Spam-Status: No, hits=0.8 tagged_above=0.0 required=5.0 tests=EMAIL_ATTRIBUTION, IN_REP_TO, RCVD_IN_NJABL, RCVD_IN_OSIRUSOFT_COM, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_MOZILLA_UA X-Spam-Level: X-Archive-Number: 200309/554 X-Sequence-Number: 43566 Tom Lane wrote: >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. > I'd opt for 2. It's quite common that newer compilers will detect more bogus coding than older ones. There might be existing functions that break from this because they rely on the current "feature", but there are probably others that will throw an exception, revealing bad coding (and delivering correct results just by chance, I've seen this more than once...) Regards, Andreas