Re: comparing rows

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

In response to

Responses

Browse pgsql-hackers by date

  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?