Re: Hmm, nodeUnique doesn't really support backwards scan too well

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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!