Resending to correct a copy/paste error. Apologies. "Kevin Grittner" <kevin.gritt...@wicourts.gov> wrote: > Yeah -- my argument would be that the = operator in NULLIF should be > treated the same as if the function-like abbreviation were rewritten > to the full CASE predicate. It doesn't surprise me that that is > taken as text, given that they are both unadorned character string > literals. The surprise here (for me at least) that the following > generates a null of type text instead of matching the non-NULL input > argument or (failing that) unknown, assuming the rewrite of > NULLIF(a, b) to the equivalent CASE predicate: > > test=# select pg_typeof(case when null = 0 then null else null end); > pg_typeof > ----------- > text > (1 row) Symmetry fails here -- NULLIF is *not* treated the same as the CASE predicate for which it is the abbreviation, which is arguably a bug-level deviation from the SQL standard. Compare the above to: test=# select pg_typeof(nullif(null, 0)); pg_typeof ----------- integer (1 row) Which is the result I would want and expect, but is inconsistent with treating it as an abbreviation of CASE. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
