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.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.
Does anyone have a take on how many people would be affected? Or how much they would be affected?
cheers
andrew
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
