"Kevin Grittner" <kevin.gritt...@wicourts.gov> writes:
> Tom Lane <t...@sss.pgh.pa.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
