Re: [HACKERS] Modify the DECLARE CURSOR command tag depending on the scrollable flag
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 update. 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? Best regards, Zoltán Böszörményi regards, tom lane -- -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt, Austria Web: http://www.postgresql-support.de http://www.postgresql.at/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Modify the DECLARE CURSOR command tag depending on the scrollable flag
On Thu, Nov 28, 2013 at 09:04:17AM +0100, Boszormenyi Zoltan wrote: Well, technically, unspecified means NO SCROLL according to the SQL standard. A lot of applications in ECPG are ported from other systems, That means by automatically adding a literal NO SCROLL to the command we obey standard, right? That's fine by me. 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. Ported applications might be in the same boat. I'm not sure if all other DBMSs stick with the standard if nothing is specified. So again, adding it might help make it clearer. Anyway, is explicitly adding NO SCROLL the preferred solution for everyone? +1 from me. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Modify the DECLARE CURSOR command tag depending on the scrollable flag
2013-11-28 09:55 keltezéssel, Michael Meskes írta: On Thu, Nov 28, 2013 at 09:04:17AM +0100, Boszormenyi Zoltan wrote: Well, technically, unspecified means NO SCROLL according to the SQL standard. A lot of applications in ECPG are ported from other systems, That means by automatically adding a literal NO SCROLL to the command we obey standard, right? That's fine by me. 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. Ported applications might be in the same boat. I'm not sure if all other DBMSs stick with the standard if nothing is specified. So again, adding it might help make it clearer. Anyway, is explicitly adding NO SCROLL the preferred solution for everyone? +1 from me. Thanks, I will rework the patches this way. Michael -- -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt, Austria Web: http://www.postgresql-support.de http://www.postgresql.at/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Modify the DECLARE CURSOR command tag depending on the scrollable flag
On Wed, 2013-11-27 at 18:17 -0500, Tom Lane wrote: 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? I wouldn't go that far yet. Do I understand this right that the future readahead code needs separate behavior depending on whether a cursor is scrollable? I would think that whatever you do with NO SCROLL cursors would also work with SCROLL cursors, so if you don't know what the cursor is, just use the code for NO SCROLL. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Modify the DECLARE CURSOR command tag depending on the scrollable flag
2013-11-29 04:56 keltezéssel, Peter Eisentraut írta: On Wed, 2013-11-27 at 18:17 -0500, Tom Lane wrote: 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? I wouldn't go that far yet. Do I understand this right that the future readahead code needs separate behavior depending on whether a cursor is scrollable? The same code is used. However, when the cursor is not scrollable, it returns an error early to the application when it wants to go backward. It still allows FETCH/MOVE ABSOLUTE to an earlier position just like the backend, in which case scanning the cursor is restarted from the beginning. If the cursor is not scrollable, the readahead code must not serve tuples from the currently populated cache backward. If the cursor is scrollable, FETCH BACKWARD is served from the cache. I would think that whatever you do with NO SCROLL cursors would also work with SCROLL cursors, so if you don't know what the cursor is, just use the code for NO SCROLL. -- -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt, Austria Web: http://www.postgresql-support.de http://www.postgresql.at/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Modify the DECLARE CURSOR command tag depending on the scrollable flag
2013-11-23 22:01 keltezéssel, Tom Lane írta: Boszormenyi Zoltan z...@cybertec.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 way there would be no incentive for lazy SQL coding using simple cursors. You can argue that it would also break application compatibility but on the other hand, such a code has always been buggy and should be fixed. 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. Yes, it can and I have a patch in the series passing this info to ecpglib. I am also arguing for backward compatibility on a different angle: this small backend change would still allow using simple cursors in ECPG while using the cursor readahead. And it's not the first time drivers have to adapt to new PostgreSQL major versions. If it was, I wouldn't have the courage to set a precedent either. Best regards, Zoltán Böszörményi -- -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt, Austria Web: http://www.postgresql-support.de http://www.postgresql.at/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Modify the DECLARE CURSOR command tag depending on the scrollable flag
Boszormenyi Zoltan z...@cybertec.at writes: 2013-11-23 22:01 keltezéssel, Tom Lane írta: Boszormenyi Zoltan z...@cybertec.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Modify the DECLARE CURSOR command tag depending on the scrollable flag
2013-11-27 19:16 keltezéssel, Tom Lane írta: Boszormenyi Zoltan z...@cybertec.at writes: 2013-11-23 22:01 keltezéssel, Tom Lane írta: Boszormenyi Zoltan z...@cybertec.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. If you read the rest of the mail, it turns out it wasn't a serious question. Getting the SCROLL / NO SCROLL flags from the preprocessor is no problem. The only problem is when it's unspecified. Treating it as NO SCROLL (or adding it to the DECLARE command behind the application's back) would break apps that want to scroll backward. (Not ABSOLUTE.) On the other hand, what problems would one face when adding SCROLL implicitly if it's unspecified? It's not a workable solution either, see below. As the documentation suggests, an application that wants to use UPDATE/DELETE WHERE CURRENT OF ..., it's highly recommended that the cursor is for a FOR UPDATE query. Watch this scenario: zozo= begin; BEGIN zozo= declare mycur cursor for select * from t1 for update; DECLARE CURSOR zozo= fetch from mycur; id | t +--- 1 | a (1 row) zozo= fetch from mycur; id | t +--- 2 | b (1 row) zozo= update t1 set t=t||'_x' where current of mycur; UPDATE 1 zozo= fetch from mycur; id | t +--- 3 | c (1 row) zozo= delete from t1 where current of mycur; DELETE 1 zozo= move absolute 0 in mycur; MOVE 0 zozo= fetch from mycur; id | t +--- 1 | a (1 row) zozo= fetch from mycur; id | t +--- (0 rows) Although the server complains about MOVE BACKWARD, it's not complaining about MOVE ABSOLUTE, despite it's clearly moving backward. The cursor position is tracked in the backend in a long variable and it's not overflowed. This is also legacy behaviour, changing it would break backward compatibility. The other problem I see is with the documentation: it says that the INSENSITIVE keyword is just a placeholder, all cursors are insensitive. It's clearly false. Moving back to the start, previously existing rows won't show up again. It's not strictly a sensitive cursor, either, because the row with id=2 would show up with the new value of t. This neither sensitive nor insensitive behaviour is what the SQL standard calls an asensitive cursor. It would worth a doc change. This is what's written in 9.3: If the cursor's query includes FOR UPDATE or FOR SHARE, then returned rows are locked at the time they are first fetched, in the same way as for a regular SELECT http://www.postgresql.org/docs/9.3/interactive/sql-select.html command with these options. In addition, the returned rows will be the most up-to-date versions; therefore these options provide the equivalent of what the SQL standard calls a sensitive cursor. (Specifying INSENSITIVE together with FOR UPDATE or FOR SHARE is an error.) ( http://www.postgresql.org/docs/9.3/interactive/sql-declare.html ) However, if the cursor is declared without FOR UPDATE, both the explicit SCROLL keyword (or implicit, if the query is simple), scrolling backward and DML with WHERE CURRENT OF are allowed. In this case, the cursor is really insensitive, FETCH statements after MOVE ABSOLUTE 0 return all rows with their original data. This is just to show that adding SCROLL behind the application's back is also pointless. If the query (which can also be a prepared statement in ECPG) contains FOR UPDATE, adding SCROLL to the DECLARE statement would make it fail. 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; then returning the SCROLL / NO SCROLL flag in the command tag is not a bad solution in my view. In fact, this was the only workable solution I could come up with to make it work reliably when neither SCROLL nor NO SCROLL is specified by the application. Best regards, Zoltán Böszörményi -- -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt, Austria Web: http://www.postgresql-support.de http://www.postgresql.at/
Re: [HACKERS] Modify the DECLARE CURSOR command tag depending on the scrollable flag
Boszormenyi Zoltan escribió: 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; then returning the SCROLL / NO SCROLL flag in the command tag is not a bad solution in my view. In fact, this was the only workable solution I could come up with to make it work reliably when neither SCROLL nor NO SCROLL is specified by the application. Would it work to have a function of some sort to which you give a cursor name and it returns whether it is scrollable or not? -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Modify the DECLARE CURSOR command tag depending on the scrollable flag
Boszormenyi Zoltan z...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Modify the DECLARE CURSOR command tag depending on the scrollable flag
On 11/27/13, 2:49 PM, Alvaro Herrera wrote: Would it work to have a function of some sort to which you give a cursor name and it returns whether it is scrollable or not? That might make sense. I think this case is similar to the question whether a view is updatable. You wouldn't put that information in the CREATE VIEW command tag. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Modify the DECLARE CURSOR command tag depending on the scrollable flag
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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Modify the DECLARE CURSOR command tag depending on the scrollable flag
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 update. I'm for it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Modify the DECLARE CURSOR command tag depending on the scrollable flag
2013-11-27 20:49 keltezéssel, Alvaro Herrera írta: Boszormenyi Zoltan escribió: 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; then returning the SCROLL / NO SCROLL flag in the command tag is not a bad solution in my view. In fact, this was the only workable solution I could come up with to make it work reliably when neither SCROLL nor NO SCROLL is specified by the application. Would it work to have a function of some sort to which you give a cursor name and it returns whether it is scrollable or not? D'oh. Yes, that would also work. Thanks for the idea. :-) I will implement it and adapt my remaining patches. Best regards, Zoltán Böszörményi -- -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt, Austria Web: http://www.postgresql-support.de http://www.postgresql.at/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Modify the DECLARE CURSOR command tag depending on the scrollable flag
Boszormenyi Zoltan z...@cybertec.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Modify the DECLARE CURSOR command tag depending on the scrollable flag
2013-11-20 14:41 keltezéssel, Boszormenyi Zoltan írta:
2013-11-12 07:15 keltezéssel, Boszormenyi Zoltan írta:
2013-11-12 07:01 keltezéssel, Noah Misch írta:
On Mon, Nov 11, 2013 at 10:17:54AM +0100, Boszormenyi Zoltan wrote:
The old contents of my GIT repository was removed so you need to
clone it fresh. https://github.com/zboszor/ecpg-readahead.git
I won't post the humongous patch again, since sending a 90KB
compressed file to everyone on the list is rude.
Patches of that weight show up on a regular basis. I don't think it's rude.
OK, here it is.
...
Subsequent patches will come as reply to this email.
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.
It is expected by the ECPG cursor readahead code.
Best regards,
Zoltán Böszörményi
--
--
Zoltán Böszörményi
Cybertec Schönig Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
http://www.postgresql.at/
commit a691e262f562debd4b8991728fddd1e0895cf907
Author: Böszörményi Zoltán z...@cybertec.at
Date: Wed Nov 20 10:50:31 2013 +0100
The backend knows whether the cursor is scrollable if neither SCROLL
nor NO SCROLL was specified. Inform the clients about this property
in the command tag: DECLARE SCROLL CURSOR or DECLARE NO SCROLL CURSOR.
The upcoming ECPG cursor handling code uses it. One contrib and some
ECPG regression tests have changed.
diff --git a/contrib/dblink/expected/dblink.out b/contrib/dblink/expected/dblink.out
index f237c43..d2b5d69 100644
--- a/contrib/dblink/expected/dblink.out
+++ b/contrib/dblink/expected/dblink.out
@@ -442,9 +442,9 @@ SELECT dblink_close('myconn','rmt_foo_cursor');
-- this should succeed because we have an open transaction
SELECT dblink_exec('myconn','DECLARE xact_test CURSOR FOR SELECT * FROM foo');
- dblink_exec
-
- DECLARE CURSOR
+ dblink_exec
+---
+ DECLARE SCROLL CURSOR
(1 row)
-- commit remote transaction
@@ -477,9 +477,9 @@ SELECT dblink_close('myconn','rmt_foo_cursor2');
-- this should succeed because we have an open transaction
SELECT dblink_exec('myconn','DECLARE xact_test CURSOR FOR SELECT * FROM foo');
- dblink_exec
-
- DECLARE CURSOR
+ dblink_exec
+---
+ DECLARE SCROLL CURSOR
(1 row)
-- this should commit the transaction
diff --git a/src/backend/commands/portalcmds.c b/src/backend/commands/portalcmds.c
index 5c3f42c..ef36d78 100644
--- a/src/backend/commands/portalcmds.c
+++ b/src/backend/commands/portalcmds.c
@@ -42,7 +42,8 @@
*/
void
PerformCursorOpen(PlannedStmt *stmt, ParamListInfo params,
- const char *queryString, bool isTopLevel)
+ const char *queryString, bool isTopLevel,
+ bool *scrollable)
{
DeclareCursorStmt *cstmt = (DeclareCursorStmt *) stmt-utilityStmt;
Portal portal;
@@ -118,6 +119,8 @@ PerformCursorOpen(PlannedStmt *stmt, ParamListInfo params,
portal-cursorOptions |= CURSOR_OPT_NO_SCROLL;
}
+ *scrollable = !!(portal-cursorOptions CURSOR_OPT_SCROLL);
+
/*
* Start execution, inserting parameters if any.
*/
diff --git a/src/backend/tcop/utility.c b/src/backend/tcop/utility.c
index 6a7bf0d..89665cc 100644
--- a/src/backend/tcop/utility.c
+++ b/src/backend/tcop/utility.c
@@ -505,11 +505,15 @@ standard_ProcessUtility(Node *parsetree,
case T_PlannedStmt:
{
PlannedStmt *stmt = (PlannedStmt *) parsetree;
+bool scrollable;
if (stmt-utilityStmt == NULL ||
!IsA(stmt-utilityStmt, DeclareCursorStmt))
elog(ERROR, non-DECLARE CURSOR PlannedStmt passed to ProcessUtility);
-PerformCursorOpen(stmt, params, queryString, isTopLevel);
+PerformCursorOpen(stmt, params, queryString, isTopLevel, scrollable);
+if (completionTag)
+ sprintf(completionTag, DECLARE %s CURSOR,
+ (scrollable ? SCROLL : NO SCROLL));
}
break;
diff --git a/src/include/commands/portalcmds.h b/src/include/commands/portalcmds.h
index b123bbd..8e756a8 100644
--- a/src/include/commands/portalcmds.h
+++ b/src/include/commands/portalcmds.h
@@ -19,7 +19,8 @@
extern void PerformCursorOpen(PlannedStmt *stmt, ParamListInfo params,
- const char *queryString, bool isTopLevel);
+ const char *queryString, bool isTopLevel,
+ bool *scrollable);
extern void PerformPortalFetch(FetchStmt *stmt, DestReceiver *dest,
char *completionTag);
diff --git a/src/interfaces/ecpg/test/expected/compat_informix-sqlda.stderr b/src/interfaces/ecpg/test/expected/compat_informix-sqlda.stderr
index f463d03..fc36a14 100644
--- a/src/interfaces/ecpg/test/expected/compat_informix-sqlda.stderr
+++ b/src/interfaces/ecpg/test/expected/compat_informix-sqlda.stderr
@@ -28,7 +28,7 @@
[NO_PID]:
