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 D0BDBD1B513; Tue,  9 Sep 2003 15:55:07 +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 26264-09; Tue,  9 Sep 2003 12:54:37 -0300 (ADT)
Received: from sss.pgh.pa.us (unknown [192.204.191.242])
	by svr1.postgresql.org (Postfix) with ESMTP
	id 419A1D1B529; Tue,  9 Sep 2003 12:54:36 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.12.9/8.12.9) with ESMTP id h89FsXAn025048;
	Tue, 9 Sep 2003 11:54:33 -0400 (EDT)
To: Manfred Koizar <mkoi-pg@aon.at>
Cc: pgsql-hackers@postgresql.org, pgsql-sql@postgresql.org
Subject: Re: plpgsql doesn't coerce boolean expressions to boolean 
In-reply-to: <2uorlv41aahh6fp3773r5pkjdnm26m4cc5@email.aon.at> 
References: <15403.1063035632@sss.pgh.pa.us>
	<2uorlv41aahh6fp3773r5pkjdnm26m4cc5@email.aon.at>
Comments: In-reply-to Manfred Koizar <mkoi-pg@aon.at>
	message dated "Tue, 09 Sep 2003 16:56:20 +0200"
Date: Tue, 09 Sep 2003 11:54:33 -0400
Message-ID: <25047.1063122873@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Archive-Number: 200309/63
X-Sequence-Number: 15041

Manfred Koizar <mkoi-pg@aon.at> writes:
> On Mon, 08 Sep 2003 11:40:32 -0400, Tom Lane <tgl@sss.pgh.pa.us>
> wrote:
>> 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.)

> I vote for 4.

I'm willing to do that.

> And - being fully aware of similar proposals having
> failed miserably - I propose to proceed as follows:

> If the current behaviour is considered a bug, let i=4, else let i=5.

> In 7.i:  Create a new GUC variable "plpgsql_strict_boolean" (silly
> name, I know) in the "VERSION/PLATFORM COMPATIBILITY" section of
> postgresql.conf.  Make the new behaviour dependent on this variable.
> Default plpgsql_strict_boolean to false.  Place a warning into the
> release notes and maybe into the plpgsql documentation.

> In 7.j, j>i:  Change the default value of plpgsql_strict_boolean to
> true.  Issue WARNINGs or NOTICEs as appropriate.  Update
> documentation.

> In 7.k, k>j:  Remove old behaviour and GUC variable.  Update
> documentation.

I'm not willing to do that much work for what is, in the greater scheme
of things, a tiny change.  If we did that for every user-visible change,
our rate of forward progress would be a mere fraction of what it is.

			regards, tom lane