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
> 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