Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 6374E47580B for ; Wed, 8 Jan 2003 22:16:42 -0500 (EST) Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34]) by postgresql.org (Postfix) with SMTP id 2B082474E42 for ; Wed, 8 Jan 2003 22:16:41 -0500 (EST) Received: (qmail 8066 invoked from network); 9 Jan 2003 03:16:45 -0000 Received: from unknown (HELO viscomail.tpf.co.jp) (100.0.0.108) by sd2.tpf-fw-c.co.jp with SMTP; 9 Jan 2003 03:16:45 -0000 Received: from tpf.co.jp (3dgateway1 [126.0.1.60]) by viscomail.tpf.co.jp (8.8.8+Sun/8.8.8) with ESMTP id MAA16408; Thu, 9 Jan 2003 12:16:44 +0900 (JST) Message-ID: <3E1CEA18.18E921A0@tpf.co.jp> Date: Thu, 09 Jan 2003 12:18:48 +0900 From: Hiroshi Inoue X-Mailer: Mozilla 4.73 [ja] (Windows NT 5.0; U) X-Accept-Language: ja MIME-Version: 1.0 To: Tom Lane Cc: Bruce Momjian , pgsql-hackers@postgresql.org Subject: Re: MOVE LAST: why? 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> <22435.1042065746@sss.pgh.pa.us> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200301/422 X-Sequence-Number: 34032 Tom Lane wrote: > > 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 :-( Honestly I'm not so enthusiastic about scrollable cursors. Even though PostgreSQL provides an efficient scrollable cursor, I would use it little unless it could survive across transactions. Anyway it's too bad that FETCH LAST means FETCH ALL. regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/