Re: Patch for 8.5, transformationHook

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> In the specific case of COALESCE, we could theoretically do that,
>> since the only computation it needs is "IS NULL" which is
>> datatype-independent.

> Well, in the SQL specification, COALESCE is defined as an abbreviation
> of the CASE predicate, so to the extent that anyone pays attention to
> the spec, this:
> COALESCE(a, b)
> should be treated identically to:
> CASE WHEN a IS NULL THEN a ELSE b END

... as indeed we do. That CASE will be handled the same way as the
COALESCE is, ie, resolve as text output for lack of a better idea.

>> In most situations, however, you can't evaluate the function without
>> knowledge of the datatype semantics. As an example, consider
>> NULLIF('0', '00'). This gives different answers if you suppose the
>> literals are text than if you suppose they are integers.

> That is the other CASE abbreviation. (The only other one.) So,
> according to how I read the spec, it should be identical to
> CASE WHEN '0' = '00' THEN NULL ELSE '0' END

Yes, and you're begging the question: what are the semantics
of that = operator? Without imputing a datatype to the literals,
you can't resolve it.

> It is probably a poor choice on the part of the standards committee to
> implement these abbreviations for the CASE predicate in a way the
> causes them to look so much like functions.

Whether it's a function has nothing to do with this. It's a question of
datatype-dependent semantics, and it would be the same no matter what
the visual appearance of the constructs was.

regards, tom lane