Re: BUG #17068: Incorrect ordering of a particular row.
От | Tom Lane |
---|---|
Тема | Re: BUG #17068: Incorrect ordering of a particular row. |
Дата | |
Msg-id | 1714546.1624370422@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #17068: Incorrect ordering of a particular row. (David Rowley <dgrowleyml@gmail.com>) |
Ответы |
Re: BUG #17068: Incorrect ordering of a particular row.
|
Список | pgsql-bugs |
David Rowley <dgrowleyml@gmail.com> writes: > On Wed, 23 Jun 2021 at 01:26, Thomas Munro <thomas.munro@gmail.com> wrote: >> If you change the SELECT list to output alias3::text, there's a >> different value there: > Yeah, if I change it to ORDER BY alias3.lastname, nullnamesb.id; > instead of ORDER BY alias3.*, nullnamesb.id; then the tie break using > btint4fastcmp() is called more often. It's also getting called with > the missing 4s which I mentioned upthread. > See the two outputs. That points me towards something weird going on > in record_cmp(). I believe Munro's point is that in some rows alias3.* is a NULL composite value, while in other rows it is a composite containing one NULL, and they don't sort the same. Presumably the former are from left-join extension while the latter come from actual table rows having NULL in that column. (I'd suspected something of the kind, but being caffeine-deprived I'd first added "alias3.* IS NULL" to the query, which of course fails to expose the difference. Thanks SQL.) In short, I see no bug here. It is kind of obscure though. regards, tom lane
В списке pgsql-bugs по дате отправления: