[
https://issues.apache.org/jira/browse/DERBY-3897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638105#action_12638105
]
Dag H. Wanvik commented on DERBY-3897:
--------------------------------------
Thanks for looking at this patch, Rick.
> 2) the function invokes SQL against the current connection
Right! I think I momentarily blindsided by the following fragment from the
reference manual's
description of the constraint clause
(http://db.apache.org/derby/docs/dev/ref/rrefsqlj13590.html#rrefsqlj13590):
The search condition must always return the same value if applied to the
same values.
*****************
Thus, it cannot contain any of the following:
Dynamic parameters (?)
Date/Time Functions (CURRENT_DATE, CURRENT_TIME, CURRENT_TIMESTAMP)
Subqueries
User Functions (such as USER, SESSION_USER, CURRENT_USER)
******************
But we are talking user defined function :)
And user defined functions could return varying values too... But with the
new DETERMINISTIC keyword, maybe we could require that? :)
In any case, the session context is set up correctly also for the check
constraint; i'll see if I can add a test
case for it.
> 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-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
> - 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.
