Subject: Re: Bug #866 related problem (ATTN Tom Lane)

From: Florian Wunderlich <[email-masked]>
Date: Tue, 11 Feb 2003 09:39:36 +0100

I can't get through to you because your spam filter blocks my SMTP
relay.

Tom Lane wrote:
> 
> > I now have a quite similar problem: while a CURSOR on a SELECT for a
> > normal query works now, I encounter the same behavior for aggregate
> > queries:
> 
> As I think I pointed out in the original discussion, backwards fetch
> doesn't work for most plan types more complex than a simple sequential
> or index scan.  This is not trivial to fix.
> 
>                         regards, tom lane

I've looked trough our exchange on the list, but there's nothing about
that.

I found another posting which I guess you mean
(http://archives.postgresql.org/pgsql-novice/2002-12/msg00222.php).

I have put a comment in the interactive documentation for now, quoting
your original mail. This really should be in the distributed
documentation for FETCH.

So can I be sure that every non-aggregate SELECT on tables joined with
unique indexes works, independent of the WHERE or ORDER BY?

Is anybody working on implementing this functionality?

Thanks,
Florian Wunderlich

---

From: Tom Lane <[email-masked]>
Date: Wed, 12 Feb 2003 18:27:01 -0500

> unique indexes works, independent of the WHERE or ORDER BY?

I would think that backwards scan on a join mostly doesn't work, but
haven't tried it in any detail.

A plan with a SORT node at the top *will* work, no matter what's under
the SORT, so ORDER BY might mask problems in some cases.

> Is anybody working on implementing this functionality?

Not me... although I have thought about at least adding enough code to
report an error in the cases that will give wrong answers.

			regards, tom lane

---

From: Florian Wunderlich <[email-masked]>
Date: Thu, 13 Feb 2003 17:27:21 +0100