Horton

Re: Modify the DECLARE CURSOR command tag depending on the scrollable flag

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Boszormenyi Zoltan <zb@cybertec.at>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Michael Meskes <meskes@postgresql.org>, Noah Misch <noah@leadboat.com>, Peter Eisentraut <peter_e@gmx.net>, Robert Haas <robertmhaas@gmail.com>, PG Hackers <pgsql-hackers@postgresql.org>, Heikki Linnakangas <hlinnakangas@vmware.com>, Bruce Momjian <bruce@momjian.us>, Hans-Jürgen Schönig <hs@cybertec.at>
Date: 2013-11-27T20:47:13Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix some "translator:" comments mangled by pgindent

  2. Make sure float4in/float8in accept all standard spellings of "infinity".

Boszormenyi Zoltan <zb@cybertec.at> writes:
> If you consider all these:

> - certain combinations of query and DECLARE stmt flags fail;
> - adding NO SCROLL is breaking backward compatibility;
> - the readahead code has to really know whether the cursor is
>    scrollable so it can behave just like the server;

If you're claiming that readahead inside ECPG will behave absolutely
transparently in all cases, I think that's bogus anyway.  Consider for
example a query that will get a divide-by-zero error when it computes
the 110th row --- but the application stops after fetching 100 rows.
Everything's fine, until you insert some readahead logic.  Queries
containing volatile functions might also not be happy about readahead.

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.

			regards, tom lane