From: | Florian Wunderlich <fwunderlich(at)devbrain(dot)de> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org, pgsql-docs(at)postgresql(dot)org |
Subject: | Re: Bug #866 related problem (ATTN Tom Lane) |
Date: | 2003-02-11 08:39:36 |
Message-ID: | 3E48B6C8.A36E5A92@hq.factor3.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-docs |
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 | Date | Subject | |
---|---|---|---|
Next Message | Alexander Stanier | 2003-02-11 13:08:09 | Referential Integrity |
Previous Message | Elias Athanasopoulos | 2003-02-10 22:13:44 | Re: cvs (7/2/2003) broken? |
From | Date | Subject | |
---|---|---|---|
Next Message | Vicki Brown | 2003-02-12 04:01:21 | discrepancy between "make check" output and documentation |
Previous Message | Eduardo | 2003-02-10 23:53:13 | PL/PGSQL TUTORIAL |