Re: Patch for 8.5, transformationHook

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "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 21:06:36
Message-ID: 4A80458C02000025000297DC@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)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 nullif(null, 0);
nullif
--------

(1 row)

-Kevin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2009-08-10 21:07:32 Re: GRANT ON ALL IN schema
Previous Message Heikki Linnakangas 2009-08-10 21:00:28 Re: GRANT ON ALL IN schema