From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "Jeff Davis" <pgsql(at)j-davis(dot)com>, "Greg Stark" <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Patch for 8.5, transformationHook |
Date: | 2009-08-10 20:26:21 |
Message-ID: | 23978.1249935981@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-08-10 20:28:01 | Re: machine-readable explain output v4 |
Previous Message | Alvaro Herrera | 2009-08-10 20:22:47 | Re: pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY |