Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
>> I'm only proposing parse-time changes for conditional
>> expressions -- the CASE predicate and its abbreviations.
>
> No, you are not; you are proposing run-time changes, specifically
> the need to coerce unknown to something else long after the point
> where the unknown is just a literal constant.
I was thinking of changing what is currently done, for example, here:
newc->coalescetype = select_common_type(pstate, newargs, "COALESCE",
NULL);
Is that so late as you say, or is there a reason that can't work?
> As far as I can see, this entire discussion turns on the complaint
> that IS NULL gives different results for plain NULL and
> ROW(NULL,NULL,...);
No, I'm not proposing any change to that. (Others are, but that's not
my focus, personally.)
> if that weren't true then we wouldn't be arguing about whether
> COALESCE is wrong.
Yeah, I am. When you have queries built based on which fields on a
QBE window are filled by a user, it's not hard to come up with a
clause like:
AND (somedate < COALESCE(NULL, NULL) OR ...)
We solved this by modifying our framework to pass down metadata about
the values in addition to the values themselves. We were always able
to look at an object's class to generate the correct literal type -- a
Date object would generate a DATE '2009-09-11' format literal; but a
NULL had been bare in that situation. We now generate CAST(NULL AS
type) whenever we insert a NULL literal, so we are no longer burned by
this. I'm just thinking that it would reduce pain for others.
-Kevin