Re: AW: Re: AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards

From: Thomas Lockhart <lockhart(at)fourpalms(dot)org>
To: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
Cc: "'thomas(at)pgsql(dot)com'" <thomas(at)pgsql(dot)com>, "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>, "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: AW: Re: AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards
Date: 2001-06-12 14:01:02
Message-ID: 3B26209E.4862B1FC@fourpalms.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> You don't mean me, no ? My comment was intended to give an argument *for*
> allowing "= NULL" to behave like "IS NULL", by saying that the "= NULL"
> syntax is not defined directly (which Tom Ivar corrected), and would thus
> only be an extension.
> Tom Lane on the other hand said, that the standard only states NULL as a
> constant for a comparison when properly cast to a datatype.

:) That's the great thing about a long discussion: at the end I'm
confused about who wants what! Anyway, istm that until we have a
comprehensive solution for the original problem (badly formed queries
from Access going through ODBC) there is more downside to removing the
extension than there is in keeping it.

Does anyone know what other ODBC drivers look like internally? Do some
of them do extensive parsing of input queries (to reliably detect the "=
NULL" construct), or are they "lightweight" like ours seems to be?

- Thomas

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Darren Johnson 2001-06-12 14:37:18 Re: AW: AW: Postgres Replication
Previous Message Alex Pilosov 2001-06-12 13:58:21 inet/cidr wierdness (casting)