[
https://issues.apache.org/jira/browse/DERBY-3897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dag H. Wanvik updated DERBY-3897:
---------------------------------
Attachment: derby-3897-2.stat
derby-3897-2.diff
Uploading revision #2 of this patch, which adds a test case for the following
case: ALTER TABLE adds a CHECK constraint that calls a user defined function
with a nested connection, to test that the substatement used by alter table to
do the checking of existing rows in the table w.r.t the new check constraint,
gets the correct session context, which is in turn inherited when the session
context is pushed to the user defined function.
(code snip):
In this case, the session context stack contains two elements referenced from
the three activations thus:
top level "ALTER TABLE" activation -> top level session context
substatement (CHECK CONSTRAINT activation) -> top level session context
nested connection in getCurrentRole,
"VALUES CURRENT_ROLE" activation -> pushed session context
Regressions ran cleanly and I verified that the new test case fails without the
patch.
> 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
> Assignee: Dag H. Wanvik
> Fix For: 10.5.0.0
>
> Attachments: derby-3897-1.diff, derby-3897-1.stat, derby-3897-2.diff,
> derby-3897-2.stat, derby-3897-repro.diff
>
>
> 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.")
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
