| 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-27 18:16:17 |
| Message-ID: | 19730.1385576177@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:
> 2013-11-23 22:01 keltezssel, Tom Lane rta:
>> 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.
> I saw code in the backend allowing a cursor to be scrollable, although
> it was not declared as such. How about ripping that out?
That also fails the unnecessary-backwards-compatibility-break test.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2013-11-27 18:18:03 | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |
| Previous Message | Tom Lane | 2013-11-27 17:54:56 | Re: Platform-dependent(?) failure in timeout handling |