[ https://issues.jboss.org/browse/TEIID-1700?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-1700: --------------------------------------- I'll looking at this as a candidate for 7.6. The main advantage of having a cursor type/logic in the engine would be for passing to procedures (and possibly functions). With generalization in/out and out could be handled as well and would no longer necessitate having only one result set. Without additional designer support though the workaround would be to pass cursors using the object type and then using a cast. One possible issue is that the PG logic has a special case for cursor execution through a portal. I'm not sure if that would remain valid if the engine were handling DECLARE CURSOR/MOVE/FETCH/CLOSE. Ramesh is there still a regular portal created in this case? JDBC access with a few enhancements (backwards fetch, better absolute positioning) still wouldn't directly need a cursor concept. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1700?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-1700: --------------------------------------- I'm specifically asking about line 458 of ODBCServerRemoteImpl, where the cursor map is being checked. We would no longer have that mapping if the cursor logic moved into the engine. http://psoug.org/reference/ref_cursors.html gives some cursor examples. This fixes the current limitation of not having a way o passing resultsets from one procedure to another. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1700?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-1700: --------------------------------------- Trying to merge the PG statement vs. embedded SQL cursors is a little tricky. The PG statement usage does not require an open statement, allows for bulk fetch/move (FORWARD/BACKWARD n), and fetch does not use an into clause. Creating the different usage rules is a validation/documentation burden. So we'll also have general support for the bulk fetch operations, but only on resolved cursors where the schema is known. Also, I think we'll leave statement level cursors undocumented. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1700?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-1700: ---------------------------------- Fix Version/s: 8.1 (was: 8.0) Pushing to 8.1. I do have a partial patch for this, but it is a significant amount of work. The chief benefit, of being able to pass cursors is still desirable, so pushing to 8.1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/TEIID-1700?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-1700: ---------------------------------- Fix Version/s: (was: 8.2) This will not get done for 8.2. Also pg uses different syntax for client and stored procedure cursors. We should primarily be interested in cursors for our procedure language and then see if that can fit into the odbc/jdbc logic. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira