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

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

From
Zeugswetter Andreas SB
Date:
> From Andreas' comments, it seems that for his application he would like
> a different behavior, but frankly I'm not certain why the current
> behavior would be detrimental in the use case he mentioned. If SQL92
> requires that any query with "= NULL" be rejected as illegal

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.

Andreas


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

From
Thomas Lockhart
Date:
> 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