Re: [HACKERS] Re: [SQL] Oddities with NULL and GROUP BY - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Re: [SQL] Oddities with NULL and GROUP BY
Date
Msg-id 29820.927125056@sss.pgh.pa.us
Whole thread Raw
In response to Re: [SQL] Oddities with NULL and GROUP BY  (Herouth Maoz <herouth@oumail.openu.ac.il>)
List pgsql-hackers
Herouth Maoz <herouth@oumail.openu.ac.il> writes:
> Thus, by rights, NULL=NULL should be true, because there is only one null
> value.

You are jumping to a conclusion not supported by the text you have
quoted.

It does appear that GROUP BY and DISTINCT should treat all nulls as
falling into the same class, because of

>     h) distinct: Two values are said to be not distinct if either:
>        both are the null value, or they compare equal according to
>        Subclause 8.2, "<comparison predicate>".

Kindly note, however, that the standards authors felt it necessary to
describe those two cases as separate cases.  If nulls compare as equal,
there would be no need to write more than "Two values are not distinct
if they compare equal".

> One should note, however, that when the actual comparison operator "=" is
> used, the standard says that if one of the operands is null, the result of
> the comparison is unknown.

Precisely.  A fortiori, if both operands are null, the result of the
comparison is still unknown.

We do seem to have a bug in GROUP BY/DISTINCT if nulls are producing
more than one output tuple in those operations.  But that has nothing
to do with what the comparison operator produces.
        regards, tom lane


pgsql-hackers by date:

Previous
From: The Hermit Hacker
Date:
Subject: Re: [HACKERS] PyGreSQL 2.4
Next
From: The Hermit Hacker
Date:
Subject: Re: [HACKERS] PyGreSQL 2.4