Message-ID: <3F5E130F.8060109@dunslane.net>
Date: Tue, 09 Sep 2003 13:51:11 -0400
From: Andrew Dunstan <andrew@dunslane.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703
MIME-Version: 1.0
To: Postgresql Hackers <pgsql-hackers@postgresql.org>
Subject: Re: 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:

>>>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.
>
>  
>
Won't people have to analyse their functions to find out what sort of 
casts they need to create? If so, why don't they just fix the functions 
while they are about it? Surely the fixes in most cases will be quite 
trivial, and in all cases backwards compatible.

Does anyone have a take on how many people would be affected? Or how 
much they would be affected?

cheers

andrew