Description
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 <colname> <coltype> 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 when executed as part of an ALTER TABLE
- 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.")
Attachments
Attachments
Issue Links
- breaks
-
DERBY-6348 NPE or assert failure in recursive trigger
-
- Closed
-
- is related to
-
DERBY-3327 SQL roles: Implement authorization stack (and SQL session context to hold it)
-
- Closed
-