Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 2046E475E83 for ; Wed, 8 Jan 2003 17:42:52 -0500 (EST) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id 8A9C7475DAD for ; Wed, 8 Jan 2003 17:42:51 -0500 (EST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.6/8.12.6) with ESMTP id h08MgR0U022436; Wed, 8 Jan 2003 17:42:27 -0500 (EST) To: Hiroshi Inoue Cc: Bruce Momjian , pgsql-hackers@postgresql.org Subject: Re: MOVE LAST: why? In-reply-to: <3E1BEFFE.88B57516@tpf.co.jp> References: <200301072329.h07NT2X28922@candle.pha.pa.us> <27934.1041984327@sss.pgh.pa.us> <3E1B9DCD.75859501@tpf.co.jp> <501.1041997832@sss.pgh.pa.us> <3E1BA5E6.9463718F@tpf.co.jp> <863.1042000401@sss.pgh.pa.us> <3E1BAFF6.B0114A67@tpf.co.jp> <1082.1042002375@sss.pgh.pa.us> <3E1BEFFE.88B57516@tpf.co.jp> Comments: In-reply-to Hiroshi Inoue message dated "Wed, 08 Jan 2003 18:31:42 +0900" Date: Wed, 08 Jan 2003 17:42:26 -0500 Message-ID: <22435.1042065746@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200301/411 X-Sequence-Number: 34021 Hiroshi Inoue writes: > I'm suspicios if we should implement scrollable cursors > with the combination of the current MOVE and FETCH implemen- > tation. For example the backwards FETCH operation for group > nodes isn't implemented properly yet(maybe). Yeah, backwards scan is not implemented for quite a large number of plan node types :-(. I am not sure that it is practical to fix them all. I have been toying with the notion of making cursors on complex plans safe for FETCH BACKWARD by sticking a MATERIAL node atop the plan, if the top plan node isn't one that can handle backwards scan. The trouble with this of course is that one of the main things people like to use cursors for is huge result sets, and materializing those is the last thing you want to do :-( regards, tom lane