Re: Hmm, nodeUnique doesn't really support backwards scan too well
| От | Gregory Stark |
|---|---|
| Тема | Re: Hmm, nodeUnique doesn't really support backwards scan too well |
| Дата | |
| Msg-id | 87hc9wsijc.fsf@oxford.xeocode.com обсуждение исходный текст |
| Ответ на | Re: Hmm, nodeUnique doesn't really support backwards scan too well (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-bugs |
"Tom Lane" <tgl@sss.pgh.pa.us> writes: > Gregory Stark <stark@enterprisedb.com> writes: >> "Tom Lane" <tgl@sss.pgh.pa.us> writes: >>> Well, if you think it's easy, the best form of criticism is a patch. >>> The change-of-direction problem seems to me to be messy --- not >>> insoluble, but messy enough to need beta testing. > >> Hm, I must have misunderstood the bug because there's a comment in nodeUnique >> which claims it already does precisely what I was suggesting: > >> * We return the first tuple from each group of duplicates (or the last >> * tuple of each group, when moving backwards). At either end of the >> * subplan, clear the result slot so that we correctly return the >> * first/last tuple when reversing direction. > > That's what it *used* to say. But the problem is that that's the wrong > behavior, because you get different tuples returned depending on which way > you are traveling. It's only workable if the tuples in a group are > completely indistinguishable. Oh egads. I see what it's trying to say now. I assumed it meant it worked *properly* meaning it returned the "last tuple of each group" returned by the child node as it scanned backwards. What it actually means it say is that it is *intentionally* behaving incorrectly! It's returning the last tuple of the set as it scans backward meaning the first tuple that comes out scanning backwards. Sigh. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support!
В списке pgsql-bugs по дате отправления: