X-Original-To: pgsql-bugs@postgresql.org Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 3068F474E5C; Tue, 11 Feb 2003 04:00:45 -0500 (EST) Received: from post.webmailer.de (natsmtp01.webmailer.de [192.67.198.81]) by postgresql.org (Postfix) with ESMTP id D9AF1474E53; Tue, 11 Feb 2003 04:00:43 -0500 (EST) Received: from faxdial.hq.factor3.com (ppp-62-245-161-171.mnet-online.de [62.245.161.171]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id KAA05482; Tue, 11 Feb 2003 10:00:34 +0100 (MET) Received: from hq.factor3.com (florian@main.hq.factor3.com [192.168.1.2]) by faxdial.hq.factor3.com (8.11.1/8.11.1) with ESMTP id h1B8dXh01767; Tue, 11 Feb 2003 09:39:33 +0100 Message-ID: <3E48B6C8.A36E5A92@hq.factor3.com> Date: Tue, 11 Feb 2003 09:39:36 +0100 From: Florian Wunderlich X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: pgsql-bugs@postgresql.org, pgsql-docs@postgresql.org Subject: Re: Bug #866 related problem (ATTN Tom Lane) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200302/41 X-Sequence-Number: 5457 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