Re: Patch for 8.5, transformationHook
От | Kevin Grittner |
---|---|
Тема | Re: Patch for 8.5, transformationHook |
Дата | |
Msg-id | 4A80469D02000025000297E8@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Patch for 8.5, transformationHook (Pavel Stehule <pavel.stehule@gmail.com>) |
Список | pgsql-hackers |
Resending to correct a copy/paste error. Apologies. "Kevin Grittner" <Kevin.Grittner@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
В списке pgsql-hackers по дате отправления: