Re: plpgsql doesn't coerce boolean expressions to boolean

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Postgresql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: plpgsql doesn't coerce boolean expressions to boolean
Date: 2003-09-09 17:51:11
Message-ID: 3F5E130F.8060109@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-sql

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2003-09-09 17:57:23 Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean
Previous Message Tom Lane 2003-09-09 17:32:09 Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean

Browse pgsql-sql by date

  From Date Subject
Next Message Bruce Momjian 2003-09-09 17:57:23 Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean
Previous Message floyds 2003-09-09 17:45:24 contrib/ltree