SQLSessionContext not correctly initialized in some non-method call nested contexts ----------------------------------------------------------------------------------- Key: DERBY-3897 URL: https://issues.apache.org/jira/browse/DERBY-3897 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.5.0.0 Reporter: Dag H. Wanvik Fix For: 10.5.0.0 In some contexts, beside calling stored routines containing SQL, Derby uses nested execution contexts, wehere we have two nested activations, but no nested connections. In such cases, currently a new SQLSessionContext is constructed, but not initialized correctly. This leads to the session variables CURRENT_ROLE/CURRENT_SCHEMA not being set correctly in these contexts (they should inherited from the parent context, cf DERBY-3327). For method calls, this is being handled by generating a call to lcc.setupNestedSessionContext (see StaticMethodCallNode#generateSetupNestedSessionContext) In some of these nested contexts, one or both of the session variables CURRENT_ROLE/CURRENT_SCHEMA can be referenced, in others not. Obviously, if they can, this will lead to errors. The following contexts will have this problem: - ALTER TABLE ADD COLUMN DEFAULT CURRENT_ROLE In the AlterTableConstantAction, a nested UPDATE statement is used to give existing rows the new column its default value. This execution context is nested, cf. AlterTableConstantAction#executeUpdate - TRIGGER body execution may reference CURRENT_ROLE/CURRENT_SCHEMA. The body executes in a nested context, cf. GenericTriggerExecutor#executeSPS. In other cases, the session variables can not be referenced, so this not a problem: - CHECK constraint execution - EmbedResultSet.insertRow, .deleteRow, .updateRow The session context should not be changed (pushed) for these nested executions, since there is no nested connection (SQL 2003, 4.37.1: "An SQL-session is associated with an SQL-connection.") -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.