You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Mamta A. Satoor (JIRA)" <de...@db.apache.org> on 2006/05/18 08:22:05 UTC
[jira] Created: (DERBY-1331) Derby's "set schema" behavior is not
compliant with SQL 2003 Foundation spec.
Derby's "set schema" behavior is not compliant with SQL 2003 Foundation spec.
-----------------------------------------------------------------------------
Key: DERBY-1331
URL: http://issues.apache.org/jira/browse/DERBY-1331
Project: Derby
Type: Bug
Reporter: Mamta A. Satoor
As per SQL2003 Foundation spec, Pg 913 Section 18.6 <set schema statement> 3b) "Otherwise, the default unqualified schema name of the current SQL-session is set to V." As per this line, set schema will only impact the current context on current SQL-session's context stack. But, in Derby, set schema is impacting all the contexts in SQL-session's context stack rather than only the current context. An example of this would be
1)make a database connection
2)set schema to 'schema1'
3)call an external procedure using CALL statement and change schema to 'schema2'
4)After the call to external procedure, check current schema
Step 3 causes a new context creation and that context gets destroyed when external procedure finishes. As per SQL2003, step 3 should only change the schema for the cotext in which the procedure is running, and step 4 should see current schema as 'schema1'. This doesn't happen in Derby. Instead, the set schema statement affects all the contexts in the SQL-session's context stack. In the example above, in step 4, Derby shows current schema to be 'schema2'.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1331) Derby's "set schema" behavior is not
compliant with SQL 2003 Foundation spec.
Posted by "Mamta A. Satoor (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1331?page=all ]
Mamta A. Satoor updated DERBY-1331:
-----------------------------------
Version: 10.1.3.1
10.1.3.0
10.1.2.1
10.1.1.0
10.0.2.1
10.0.2.0
> Derby's "set schema" behavior is not compliant with SQL 2003 Foundation spec.
> -----------------------------------------------------------------------------
>
> Key: DERBY-1331
> URL: http://issues.apache.org/jira/browse/DERBY-1331
> Project: Derby
> Type: Bug
> Components: SQL
> Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.0, 10.1.3.1
> Reporter: Mamta A. Satoor
>
> As per SQL2003 Foundation spec, Pg 913 Section 18.6 <set schema statement> 3b) "Otherwise, the default unqualified schema name of the current SQL-session is set to V." As per this line, set schema will only impact the current context on current SQL-session's context stack. But, in Derby, set schema is impacting all the contexts in SQL-session's context stack rather than only the current context. An example of this would be
> 1)make a database connection
> 2)set schema to 'schema1'
> 3)call an external procedure using CALL statement and change schema to 'schema2'
> 4)After the call to external procedure, check current schema
> Step 3 causes a new context creation and that context gets destroyed when external procedure finishes. As per SQL2003, step 3 should only change the schema for the cotext in which the procedure is running, and step 4 should see current schema as 'schema1'. This doesn't happen in Derby. Instead, the set schema statement affects all the contexts in the SQL-session's context stack. In the example above, in step 4, Derby shows current schema to be 'schema2'.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-1331) Derby's "set schema" behavior is not
compliant with SQL 2003 Foundation spec.
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dag H. Wanvik reassigned DERBY-1331:
------------------------------------
Assignee: Dag H. Wanvik
> Derby's "set schema" behavior is not compliant with SQL 2003 Foundation spec.
> -----------------------------------------------------------------------------
>
> Key: DERBY-1331
> URL: https://issues.apache.org/jira/browse/DERBY-1331
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1
> Reporter: Mamta A. Satoor
> Assignee: Dag H. Wanvik
>
> As per SQL2003 Foundation spec, Pg 913 Section 18.6 <set schema statement> 3b) "Otherwise, the default unqualified schema name of the current SQL-session is set to V." As per this line, set schema will only impact the current context on current SQL-session's context stack. But, in Derby, set schema is impacting all the contexts in SQL-session's context stack rather than only the current context. An example of this would be
> 1)make a database connection
> 2)set schema to 'schema1'
> 3)call an external procedure using CALL statement and change schema to 'schema2'
> 4)After the call to external procedure, check current schema
> Step 3 causes a new context creation and that context gets destroyed when external procedure finishes. As per SQL2003, step 3 should only change the schema for the cotext in which the procedure is running, and step 4 should see current schema as 'schema1'. This doesn't happen in Derby. Instead, the set schema statement affects all the contexts in the SQL-session's context stack. In the example above, in step 4, Derby shows current schema to be 'schema2'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1331) Derby's "set schema" behavior is not
compliant with SQL 2003 Foundation spec.
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12594367#action_12594367 ]
Dag H. Wanvik commented on DERBY-1331:
--------------------------------------
Yes, please see SQLSessionContextTest, which contains tests for SET SCHEMA as well as SET ROLE.
DERBY-3327 also contains a release note that covers the new behavior.
> Derby's "set schema" behavior is not compliant with SQL 2003 Foundation spec.
> -----------------------------------------------------------------------------
>
> Key: DERBY-1331
> URL: https://issues.apache.org/jira/browse/DERBY-1331
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1
> Reporter: Mamta A. Satoor
> Assignee: Dag H. Wanvik
> Fix For: 10.5.0.0
>
>
> As per SQL2003 Foundation spec, Pg 913 Section 18.6 <set schema statement> 3b) "Otherwise, the default unqualified schema name of the current SQL-session is set to V." As per this line, set schema will only impact the current context on current SQL-session's context stack. But, in Derby, set schema is impacting all the contexts in SQL-session's context stack rather than only the current context. An example of this would be
> 1)make a database connection
> 2)set schema to 'schema1'
> 3)call an external procedure using CALL statement and change schema to 'schema2'
> 4)After the call to external procedure, check current schema
> Step 3 causes a new context creation and that context gets destroyed when external procedure finishes. As per SQL2003, step 3 should only change the schema for the cotext in which the procedure is running, and step 4 should see current schema as 'schema1'. This doesn't happen in Derby. Instead, the set schema statement affects all the contexts in the SQL-session's context stack. In the example above, in step 4, Derby shows current schema to be 'schema2'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1331) Derby's "set schema" behavior is not
compliant with SQL 2003 Foundation spec.
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12594250#action_12594250 ]
Dag H. Wanvik commented on DERBY-1331:
--------------------------------------
Are you OK with closing this issue, Mamta?
> Derby's "set schema" behavior is not compliant with SQL 2003 Foundation spec.
> -----------------------------------------------------------------------------
>
> Key: DERBY-1331
> URL: https://issues.apache.org/jira/browse/DERBY-1331
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1
> Reporter: Mamta A. Satoor
> Assignee: Dag H. Wanvik
> Fix For: 10.5.0.0
>
>
> As per SQL2003 Foundation spec, Pg 913 Section 18.6 <set schema statement> 3b) "Otherwise, the default unqualified schema name of the current SQL-session is set to V." As per this line, set schema will only impact the current context on current SQL-session's context stack. But, in Derby, set schema is impacting all the contexts in SQL-session's context stack rather than only the current context. An example of this would be
> 1)make a database connection
> 2)set schema to 'schema1'
> 3)call an external procedure using CALL statement and change schema to 'schema2'
> 4)After the call to external procedure, check current schema
> Step 3 causes a new context creation and that context gets destroyed when external procedure finishes. As per SQL2003, step 3 should only change the schema for the cotext in which the procedure is running, and step 4 should see current schema as 'schema1'. This doesn't happen in Derby. Instead, the set schema statement affects all the contexts in the SQL-session's context stack. In the example above, in step 4, Derby shows current schema to be 'schema2'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-1331) Derby's "set schema" behavior is not
compliant with SQL 2003 Foundation spec.
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mamta A. Satoor closed DERBY-1331.
----------------------------------
Dag, thanks for taking care of this issue while tackline DERBY-3327. I will go ahead and close this issue. Can you please confirm if there were tests added for DERBY-1331?
> Derby's "set schema" behavior is not compliant with SQL 2003 Foundation spec.
> -----------------------------------------------------------------------------
>
> Key: DERBY-1331
> URL: https://issues.apache.org/jira/browse/DERBY-1331
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1
> Reporter: Mamta A. Satoor
> Assignee: Dag H. Wanvik
> Fix For: 10.5.0.0
>
>
> As per SQL2003 Foundation spec, Pg 913 Section 18.6 <set schema statement> 3b) "Otherwise, the default unqualified schema name of the current SQL-session is set to V." As per this line, set schema will only impact the current context on current SQL-session's context stack. But, in Derby, set schema is impacting all the contexts in SQL-session's context stack rather than only the current context. An example of this would be
> 1)make a database connection
> 2)set schema to 'schema1'
> 3)call an external procedure using CALL statement and change schema to 'schema2'
> 4)After the call to external procedure, check current schema
> Step 3 causes a new context creation and that context gets destroyed when external procedure finishes. As per SQL2003, step 3 should only change the schema for the cotext in which the procedure is running, and step 4 should see current schema as 'schema1'. This doesn't happen in Derby. Instead, the set schema statement affects all the contexts in the SQL-session's context stack. In the example above, in step 4, Derby shows current schema to be 'schema2'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-1331) Derby's "set schema" behavior is not
compliant with SQL 2003 Foundation spec.
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dag H. Wanvik resolved DERBY-1331.
----------------------------------
Resolution: Fixed
Fix Version/s: 10.5.0.0
Solved by DERBY-3327, resolving. That patch also contains a release note for the changed behavior.
> Derby's "set schema" behavior is not compliant with SQL 2003 Foundation spec.
> -----------------------------------------------------------------------------
>
> Key: DERBY-1331
> URL: https://issues.apache.org/jira/browse/DERBY-1331
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1
> Reporter: Mamta A. Satoor
> Assignee: Dag H. Wanvik
> Fix For: 10.5.0.0
>
>
> As per SQL2003 Foundation spec, Pg 913 Section 18.6 <set schema statement> 3b) "Otherwise, the default unqualified schema name of the current SQL-session is set to V." As per this line, set schema will only impact the current context on current SQL-session's context stack. But, in Derby, set schema is impacting all the contexts in SQL-session's context stack rather than only the current context. An example of this would be
> 1)make a database connection
> 2)set schema to 'schema1'
> 3)call an external procedure using CALL statement and change schema to 'schema2'
> 4)After the call to external procedure, check current schema
> Step 3 causes a new context creation and that context gets destroyed when external procedure finishes. As per SQL2003, step 3 should only change the schema for the cotext in which the procedure is running, and step 4 should see current schema as 'schema1'. This doesn't happen in Derby. Instead, the set schema statement affects all the contexts in the SQL-session's context stack. In the example above, in step 4, Derby shows current schema to be 'schema2'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1331) Derby's "set schema" behavior is not
compliant with SQL 2003 Foundation spec.
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1331?page=all ]
Kathey Marsden updated DERBY-1331:
----------------------------------
Component: SQL
> Derby's "set schema" behavior is not compliant with SQL 2003 Foundation spec.
> -----------------------------------------------------------------------------
>
> Key: DERBY-1331
> URL: http://issues.apache.org/jira/browse/DERBY-1331
> Project: Derby
> Type: Bug
> Components: SQL
> Reporter: Mamta A. Satoor
>
> As per SQL2003 Foundation spec, Pg 913 Section 18.6 <set schema statement> 3b) "Otherwise, the default unqualified schema name of the current SQL-session is set to V." As per this line, set schema will only impact the current context on current SQL-session's context stack. But, in Derby, set schema is impacting all the contexts in SQL-session's context stack rather than only the current context. An example of this would be
> 1)make a database connection
> 2)set schema to 'schema1'
> 3)call an external procedure using CALL statement and change schema to 'schema2'
> 4)After the call to external procedure, check current schema
> Step 3 causes a new context creation and that context gets destroyed when external procedure finishes. As per SQL2003, step 3 should only change the schema for the cotext in which the procedure is running, and step 4 should see current schema as 'schema1'. This doesn't happen in Derby. Instead, the set schema statement affects all the contexts in the SQL-session's context stack. In the example above, in step 4, Derby shows current schema to be 'schema2'.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1331) Derby's "set schema" behavior is not
compliant with SQL 2003 Foundation spec.
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12594991#action_12594991 ]
Mamta A. Satoor commented on DERBY-1331:
----------------------------------------
Thanks for adding the required tests and the release note coverage of the issue.
> Derby's "set schema" behavior is not compliant with SQL 2003 Foundation spec.
> -----------------------------------------------------------------------------
>
> Key: DERBY-1331
> URL: https://issues.apache.org/jira/browse/DERBY-1331
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1
> Reporter: Mamta A. Satoor
> Assignee: Dag H. Wanvik
> Fix For: 10.5.0.0
>
>
> As per SQL2003 Foundation spec, Pg 913 Section 18.6 <set schema statement> 3b) "Otherwise, the default unqualified schema name of the current SQL-session is set to V." As per this line, set schema will only impact the current context on current SQL-session's context stack. But, in Derby, set schema is impacting all the contexts in SQL-session's context stack rather than only the current context. An example of this would be
> 1)make a database connection
> 2)set schema to 'schema1'
> 3)call an external procedure using CALL statement and change schema to 'schema2'
> 4)After the call to external procedure, check current schema
> Step 3 causes a new context creation and that context gets destroyed when external procedure finishes. As per SQL2003, step 3 should only change the schema for the cotext in which the procedure is running, and step 4 should see current schema as 'schema1'. This doesn't happen in Derby. Instead, the set schema statement affects all the contexts in the SQL-session's context stack. In the example above, in step 4, Derby shows current schema to be 'schema2'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1331) Derby's "set schema" behavior is not
compliant with SQL 2003 Foundation spec.
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569963#action_12569963 ]
Dag H. Wanvik commented on DERBY-1331:
--------------------------------------
The work on DERBY-3327 contains a patch which would solve this issue, if committed, so linking.
> Derby's "set schema" behavior is not compliant with SQL 2003 Foundation spec.
> -----------------------------------------------------------------------------
>
> Key: DERBY-1331
> URL: https://issues.apache.org/jira/browse/DERBY-1331
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1
> Reporter: Mamta A. Satoor
>
> As per SQL2003 Foundation spec, Pg 913 Section 18.6 <set schema statement> 3b) "Otherwise, the default unqualified schema name of the current SQL-session is set to V." As per this line, set schema will only impact the current context on current SQL-session's context stack. But, in Derby, set schema is impacting all the contexts in SQL-session's context stack rather than only the current context. An example of this would be
> 1)make a database connection
> 2)set schema to 'schema1'
> 3)call an external procedure using CALL statement and change schema to 'schema2'
> 4)After the call to external procedure, check current schema
> Step 3 causes a new context creation and that context gets destroyed when external procedure finishes. As per SQL2003, step 3 should only change the schema for the cotext in which the procedure is running, and step 4 should see current schema as 'schema1'. This doesn't happen in Derby. Instead, the set schema statement affects all the contexts in the SQL-session's context stack. In the example above, in step 4, Derby shows current schema to be 'schema2'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1331) Derby's "set schema" behavior is not
compliant with SQL 2003 Foundation spec.
Posted by "Mamta A. Satoor (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1331?page=comments#action_12412297 ]
Mamta A. Satoor commented on DERBY-1331:
----------------------------------------
Fixing this might cause existing applications to break since they might be written based on Derby's current behavior for 'set schema'.
> Derby's "set schema" behavior is not compliant with SQL 2003 Foundation spec.
> -----------------------------------------------------------------------------
>
> Key: DERBY-1331
> URL: http://issues.apache.org/jira/browse/DERBY-1331
> Project: Derby
> Type: Bug
> Reporter: Mamta A. Satoor
>
> As per SQL2003 Foundation spec, Pg 913 Section 18.6 <set schema statement> 3b) "Otherwise, the default unqualified schema name of the current SQL-session is set to V." As per this line, set schema will only impact the current context on current SQL-session's context stack. But, in Derby, set schema is impacting all the contexts in SQL-session's context stack rather than only the current context. An example of this would be
> 1)make a database connection
> 2)set schema to 'schema1'
> 3)call an external procedure using CALL statement and change schema to 'schema2'
> 4)After the call to external procedure, check current schema
> Step 3 causes a new context creation and that context gets destroyed when external procedure finishes. As per SQL2003, step 3 should only change the schema for the cotext in which the procedure is running, and step 4 should see current schema as 'schema1'. This doesn't happen in Derby. Instead, the set schema statement affects all the contexts in the SQL-session's context stack. In the example above, in step 4, Derby shows current schema to be 'schema2'.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira