From: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jan Wieck <JanWieck(at)Yahoo(dot)com>, pgsql-hackers(at)postgresql(dot)org, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: [HACKERS] plpgsql doesn't coerce boolean expressions to boolean |
Date: | 2003-09-10 01:56:31 |
Message-ID: | 3F5E84CF.6090706@Yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-sql |
Tom Lane wrote:
> Jan Wieck <JanWieck(at)Yahoo(dot)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(at)Yahoo(dot)com #
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Yarra | 2003-09-10 02:07:42 | Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...) |
Previous Message | Nico King | 2003-09-10 01:54:10 | Re: Temp tables and copy |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruno Wolff III | 2003-09-10 03:17:37 | Re: How can I optimize this query |
Previous Message | Barry Lind | 2003-09-10 00:27:52 | Re: contrib/ltree |