2013-11-28 00:17 keltezéssel, Tom Lane írta:
Peter Eisentraut <pete...@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
I'm for it.
If all such apps are expected to be ported from other system,
then yes, that would also work. However, I am not so sure about this.
One thing is sure. With this change, ecpglib can still work with
older PostgreSQL versions but the application's behaviour changes
if the cursor doesn't have an explicit SCROLL/NO SCROLL.
In my first mail yesterday, I wrote "such a code has always been
buggy and should be fixed" and I meant it seriously.
I was only half serious with ripping this support code out of the backend.
However, this feature might be deprecated and removed in about
3 major release or what the usual policy is. Inconsistency between
different clients is also no good. You can only enforce similar client
behaviour with the server behaviour.
Anyway, is explicitly adding NO SCROLL the preferred solution for everyone?
regards, tom lane
Cybertec Schönig & Schönig GmbH
A-2700 Wiener Neustadt, Austria
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: