From: Andrew Dunstan <andrew@dunslane.net>
To: Postgresql Hackers <pgsql-hackers@postgresql.org>
Subject: Re: plpgsql doesn't coerce boolean expressions to boolean
Date: Tue, 09 Sep 2003 13:51:11 -0400
Message-ID: <3F5E130F.8060109@dunslane.net> (raw)
In-Reply-To: <3559.1063128729@sss.pgh.pa.us>
References: <15403.1063035632@sss.pgh.pa.us>
<3F5E0A5D.2010803@Yahoo.com>
<3559.1063128729@sss.pgh.pa.us>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: andrew@dunslane.net, pgsql-hackers@postgresql.org
Subject: Re: plpgsql doesn't coerce boolean expressions to boolean
In-Reply-To: <3F5E130F.8060109@dunslane.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox