Re: [HACKERS] Re: [SQL] Oddities with NULL and GROUP BY
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Re: [SQL] Oddities with NULL and GROUP BY |
Дата | |
Msg-id | 29820.927125056@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [SQL] Oddities with NULL and GROUP BY (Herouth Maoz <herouth@oumail.openu.ac.il>) |
Список | 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 по дате отправления: