X-Original-To: pgsql-hackers@postgreSQL.org Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id 3201747617D; Mon, 10 Mar 2003 09:40:52 -0500 (EST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.8/8.12.8) with ESMTP id h2AEetub017077; Mon, 10 Mar 2003 09:40:55 -0500 (EST) To: "Zeugswetter Andreas SB SD" Cc: "Hannu Krosing" , pgsql-hackers@postgreSQL.org, pgsql-sql@postgreSQL.org Subject: Re: Cursors and backwards scans and SCROLL In-reply-to: <46C15C39FEB2C44BA555E356FBCD6FA4961F53@m0114.s-mxs.net> References: <46C15C39FEB2C44BA555E356FBCD6FA4961F53@m0114.s-mxs.net> Comments: In-reply-to "Zeugswetter Andreas SB SD" message dated "Mon, 10 Mar 2003 10:29:19 +0100" Date: Mon, 10 Mar 2003 09:40:55 -0500 Message-ID: <17076.1047307255@sss.pgh.pa.us> From: Tom Lane X-Archive-Number: 200303/340 X-Sequence-Number: 36586 "Zeugswetter Andreas SB SD" writes: >> but just give a warning and then run the underlying >> query _again_, this toime with materialize on top and also do a Move to >> reposition the cursor. This will probably not work correctly for all >> tranasaction isolation levels though but it will penalize only these >> cases that absolutely need it. The penalty will of course be >> heavier ;( > rescan can only work in serializable isolation, no? I had thought about this and concluded it was not worth the trouble. It could be made to work if we copy the snapshot data from old plan to new, but realistically there's no value in it. Existing applications that are successfully using backwards-fetch are using queries that don't need materialization; therefore there's no compatibility gain from adding this extra code. regards, tom lane