Thanks Craig,
The real problem here then is that the documentation showing
the boolean comparison operators does not mention this quirk, which I=20
accept may be a standard quirk but it's still a quirk. You just
wouldn't go looking for that flag unless you had any inkling that
it might exist.
And indeed the parser does not generate warnings either.
Regards,
Michael
-----Original Message-----
From: Craig Ringer [mailto:craig@postnewspapers.com.au]
Sent: Sun 6/19/2011 6:30 PM
To: Kevin Grittner
Cc: Pilling, Michael; pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #6064: !=3D NULL, <> NULL do not work
=20
On 06/17/2011 10:20 PM, Kevin Grittner wrote:
> "Michael Pilling"<Michael.Pilling@dsto.defence.gov.au> wrote:
>
>> A reasonable programmer would expect !=3D NULL,<> NULL and IS NOT
>> NULL to be synonyms.
>
> Only if that programmer was not aware of the SQL standard and had
> not worked much with a standard-conforming database.
Yep, and if they want to continue working that way, they can use the=20
flag intended for compatibility with Microsoft Access that makes NULL =3D=
=20
NULL result in 't' instead of NULL.
http://www.postgresql.org/docs/current/static/runtime-config-compatible.htm=
l#GUC-TRANSFORM-NULL-EQUALS
Note that this flag is very specifically limited to equality=20
comparisions using the '=3D' operator. It won't make NULL behave as a=20
value in any other way. For example, 1 > NULL will still return NULL.
--
Craig Ringer
IMPORTANT: This email remains the property of the Department of Defence and=
is subject to the jurisdiction of section 70 of the Crimes Act 1914. If yo=
u have received this email in error, you are requested to contact the sende=
r and delete the email.
