Message-ID: <3F5E84CF.6090706@Yahoo.com>
Date: Tue, 09 Sep 2003 21:56:31 -0400
From: Jan Wieck <JanWieck@Yahoo.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jan Wieck <JanWieck@Yahoo.com>, pgsql-hackers@postgresql.org,
	pgsql-sql@postgresql.org
Subject: Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean
References: <15403.1063035632@sss.pgh.pa.us> <3F5E0A5D.2010803@Yahoo.com>
	<3559.1063128729@sss.pgh.pa.us>
In-Reply-To: <3559.1063128729@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Tom Lane wrote:
> Jan Wieck <JanWieck@Yahoo.com> writes:
>> ERROR is the cleanest way, but I'd vote for conversion to boolean to 
>> keep the damage within reason.
> 
> Which style of conversion did you like?  These were the choices:
> 
>>> 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.)
> 
> At this point I'm kinda leaning to #4, because (for example) people
> could create a cast from integer to boolean to avoid having to fix their
> plpgsql functions right away.  #3 would not offer any configurability of
> behavior.

Agreed - #4.

Thinking of the problem about deprication of features and transition 
time, it would be nice for this kind of compatibility breaking changes 
to have a _per database_ config option that controls old vs. new 
behaviour, wouldn't it? Don't know exactly how you'd like that to be. 
Maybe with a pg_config catalog that inherits default settings from 
template1 but can then be changed in every database. This would even 
include the possibility to *switch* one single prod database back to the 
old behaviour in case the supposedly cleaned up application isn't as 
clean as supposed to.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #