Re: comparing rows

Поиск
Список
Период
Сортировка
От Thomas Lockhart
Тема Re: comparing rows
Дата
Msg-id 398A6621.D203125F@alumni.caltech.edu
обсуждение исходный текст
Ответ на RE: comparing rows  (Magnus Hagander <mha@sollentuna.net>)
Ответы Re: comparing rows  (The Hermit Hacker <scrappy@hub.org>)
Список 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Anyone particularly wedded to func_tlist mechanism?
Следующее
От: Peter Mount
Дата:
Сообщение: RE: pg_dump/restore to convert BLOBs to LZTEXT (optiona l!)