Craig Ringer <craig@2ndquadrant.com> writes:
> On 05/12/2014 10:18 AM, Craig Ringer wrote:
>> Do we need a way to schema-qualify the operator used in NULLIF, or to
>> provide an operator alias that it gets dumped as?
> This looks like a bug that'll want backpatching and it's not a data loss
> risk, so I don't think it's urgent to shove this in before 9.4 closes.
FWIW, I don't think this is something we ought to back-patch. NULLIF
is effectively defined in terms of "a = b", where the = operator is
whatever would be found by operator lookup. It's probably better to
look for a default btree opclass, but that's a different behavior;
and one that will have its own failure modes, particularly if a and b
aren't of the same type.
It is worth noting that the SQL standard says in so many words:
NULLIF (V1, V2) is equivalent to the following <case specification>:
CASE WHEN V1=V2 THEN NULL ELSE V1 END
Now, you can argue about how literally they mean that; for one thing
I doubt they want you to evaluate V1 twice. But nonetheless the
construct is defined in terms of an operator named "=".
Also, I think we still have some other dependencies on assumed
operator names in eg. CASE. Cleaning up only NULLIF may not be a
full solution.
There have been past discussions of whether we ought to follow the
letter or the spirit of the standard's references to "=" and other
operators. Don't recall if we came to any definitive conclusions,
but right now we're clearly not totally consistent on this point.
regards, tom lane
