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
