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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Boszormenyi Zoltan <zb(at)cybertec(dot)at>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Michael Meskes <meskes(at)postgresql(dot)org>, Noah Misch <noah(at)leadboat(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Hans-Jürgen Schönig <hs(at)cybertec(dot)at>
Subject: Re: Modify the DECLARE CURSOR command tag depending on the scrollable flag
Date: 2013-11-23 21:01:26
Message-ID: 21369.1385240486@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Boszormenyi Zoltan <zb(at)cybertec(dot)at> writes:
> Attached is the patch that modified the command tag returned by
> the DECLARE CURSOR command. It returns "DECLARE SCROLL CURSOR"
> or "DECLARE NO SCROLL CURSOR" depending on the cursor's
> scrollable flag that can be determined internally even if neither is
> asked explicitly.

This does not strike me as an acceptable change. It will break any code
that's expecting the existing command tag, for little or no benefit
to most applications. Even if backwards compatibility were of no concern,
I'm not convinced it's a good thing to expose the backend's internal
choices about query plans used for cursors, which is what this is
basically doing.

> It is expected by the ECPG cursor readahead code.

And that doesn't sound like a sufficient excuse. You should only assume a
cursor is scrollable if SCROLL was specified in the cursor declaration
command, which it'd seem to me is something ECPG would or easily could
know about commands it issues.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2013-11-23 21:02:54 Re: Logging WAL when updating hintbit
Previous Message Sebastian Hilbert 2013-11-23 18:45:11 Re: [GENERAL] pg_upgrade ?deficiency