From: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Magnus Hagander <mha(at)sollentuna(dot)net>, Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: comparing rows |
Date: | 2000-08-04 06:43:45 |
Message-ID: | 398A6621.D203125F@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > 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
already.
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$.
Oh, and
5) Thomas will continue to complain about M$ for shipping products with
gratuitous deviations from published standards. ;)
- Thomas
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Mount | 2000-08-04 06:55:52 | RE: [HACKERS] pg_dump/restore to convert BLOBs to LZTEXT (optiona l!) |
Previous Message | Tom Lane | 2000-08-04 06:30:21 | Re: Anyone particularly wedded to func_tlist mechanism? |