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 362B0474E42; Sun, 9 Mar 2003 16:18:09 -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 h29LIAub025933; Sun, 9 Mar 2003 16:18:10 -0500 (EST) To: Rod Taylor Cc: PostgreSQL Development , pgsql-sql@postgresql.org Subject: Re: Cursors and backwards scans and SCROLL In-reply-to: <1047243868.28251.217.camel@jester> References: <21621.1047242111@sss.pgh.pa.us> <1047243868.28251.217.camel@jester> Comments: In-reply-to Rod Taylor message dated "09 Mar 2003 16:04:28 -0500" Date: Sun, 09 Mar 2003 16:18:10 -0500 Message-ID: <25932.1047244690@sss.pgh.pa.us> From: Tom Lane X-Archive-Number: 200303/322 X-Sequence-Number: 36568 Rod Taylor writes: > Enforcing spec seems like the least confusing mode to operate under, > especially given it could break simply by changing the plan -- which > happens automagically (seemingly random). Keep in mind though that complaints about the current bugs have been fairly infrequent, which means that most people either don't try to fetch backwards from a cursor, or don't try to do so on complex plans. I'm hesitant to penalize a larger group for the benefit of a smaller one --- which is why enforcing the spec strictly doesn't really appeal to me, even though one could argue that the larger group had it coming. I'd prefer to be permissive about the cases that we can support at no cost, which not-by-coincidence are the cases that have worked correctly up to now. regards, tom lane