From: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
---|---|
To: | "tneumann(at)users(dot)sourceforge(dot)net" <tneumann(at)users(dot)sourceforge(dot)net>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #12462: NULLIF changes the argument type |
Date: | 2015-01-08 16:45:45 |
Message-ID: | 311243186.3874557.1420735545628.JavaMail.yahoo@jws100104.mail.ne1.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
"tneumann(at)users(dot)sourceforge(dot)net" <tneumann(at)users(dot)sourceforge(dot)net> wrote:
> The SQL standard in Section 6.11, Syntax rule 1 c) says that
>
> ""
> NULLIF (V1, V2) is equivalent to the following <case specification>:
> CASE WHEN
> V1=V2 THEN
> NULL ELSE V1
> END
> ""
>
> which is currently not the case in Postgres. Postgres promotes V1 to the
> type of V2, which can lead to behavior changes.
>
> Example query as illustration: It should produce 0,0,0 (and does on SQL
> Server and DB2), but PostgreSQL promotes the type and produces 0,0.5,0
>
> select 1/2,nullif(1,2.3)/2,case when 1=2.3 then NULL else 1 end/2
I agree that this fails to conform to the standard and should be
considered a bug. FWIW, Oracle, SQL Lite, and MySQL also return
matching values for the three columns in your sample query;
although Oracle and MySQL return 0.5,0.5,0.5 instead of 0,0,0.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Aaron Botsis | 2015-01-08 20:05:10 | Re: Patch: [BUGS] BUG #12320: json parsing with embedded double quotes |
Previous Message | tneumann | 2015-01-08 16:11:55 | BUG #12462: NULLIF changes the argument type |