Re: Modify the DECLARE CURSOR command tag depending on the scrollable flag - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Modify the DECLARE CURSOR command tag depending on the scrollable flag
Date
Msg-id 9328.1385594236@sss.pgh.pa.us
Whole thread Raw
In response to Re: Modify the DECLARE CURSOR command tag depending on the scrollable flag  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Modify the DECLARE CURSOR command tag depending on the scrollable flag  (Boszormenyi Zoltan <zb@cybertec.at>)
Re: Modify the DECLARE CURSOR command tag depending on the scrollable flag  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> On 11/27/13, 3:47 PM, Tom Lane wrote:
>> Given these considerations, I think it'd be better to allow explicit
>> application control over whether read-ahead happens for a particular
>> query.  And I have no problem whatsoever with requiring that the cursor
>> be explicitly marked SCROLL or NO SCROLL before read-ahead will occur.

> Well, technically, unspecified means NO SCROLL according to the SQL
> standard.  A lot of applications in ECPG are ported from other systems,
> which might make that assumption.  It wouldn't be very nice to have to
> change all that.

Hm.  So you're suggesting that ECPG fix this problem by inserting an
explicit NO SCROLL clause into translated DECLARE CURSOR commands, if
there's not a SCROLL clause?

That would solve the problem of the ECPG library not being sure which
behavior applies, but it might break existing apps that were unknowingly
relying on a simple cursor being scrollable.  OTOH any such app would be
subject to breakage anyway as a result of planner changes, so it's hard to
complain against this, as long as it's happening in a major version
update.

I'm for it.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: MultiXact bugs
Next
From: Noah Misch
Date:
Subject: Re: Incomplete freezing when truncating a relation during vacuum