> > btw, it appears that SQL99 (haven't checked SQL92) specifies that
> > test=# select (1,2,3) = (1,2,null);
> > ?column?
> > ----------
> > (1 row)
> > should return FALSE, not NULL.
> What? If so, they broke it pretty badly. This should be equivalent to
> 1 = 1 AND 2 = 2 AND 3 = NULL, which should reduce to TRUE AND TRUE AND NULL,
> which should reduce to NULL. Anything else is not self-consistent.
Hmm. I could have sworn I looked this up (and was suprised at the
result). But I'm not finding the example anywhere, and Section 8.2
General Rule 1 seems to indicate that we do the right thing here
Also, I *think* we have settled on the following facts:
1) "3 = NULL" is typical of an expression generated by M$ Access.
2) "3 = NULL" is *not* legal SQL9x syntax, which specifies "3 IS NULL"
for the comparison "does three have a value of NULL?".
3) New versions of M$ Access continue to generate bogus queries
containing these comparisons.
4) Postgres will continue to understand (at least) the special case of
"column/value = NULL" to retain compatibility with M$.
5) Thomas will continue to complain about M$ for shipping products with
gratuitous deviations from published standards. ;)
In response to
pgsql-hackers by date
|Next:||From: Peter Mount||Date: 2000-08-04 06:55:52|
|Subject: RE: [HACKERS] pg_dump/restore to convert BLOBs to LZTEXT (optional!) |
|Previous:||From: Tom Lane||Date: 2000-08-04 06:30:21|
|Subject: Re: Anyone particularly wedded to func_tlist mechanism? |