[
https://issues.apache.org/jira/browse/DERBY-3137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563798#action_12563798
]
Dag H. Wanvik commented on DERBY-3137:
--------------------------------------
> If NULL is disallowed as a role name in SET ROLE then Derby should
> follow that rule, not use NULL to mean NONE, especially when the SQL
> standard was corrected to not allow the value expression to resolve to
> the special meaning of NONE.
So this would mean one could not set a role to NONE using a prepared
statement with a ? marker, one would need a separate prepared
statement for the NONE case. I don't see why the standard needs to be
so strict here.. But I can tighten this up, sure. I agree with your
general point thats its better to be tight now and then loosen up rather than
vice versa.
> Also for the TRIM case, I can't see any benefit to deviating from the
> standard.
Right, I did consider this, but was I stumped by the case of delimited
identifiers: If such identifiers could legally contain leading or
trailing blanks, one could not use them in a <value specification> in
set role statement? I chose to follow the example of the SET SCHEMA
case, which is similary not compliant in this matter, AFAICT. Should
that be tightened up as well?
> SQL roles: add catalog support
> ------------------------------
>
> Key: DERBY-3137
> URL: https://issues.apache.org/jira/browse/DERBY-3137
> Project: Derby
> Issue Type: New Feature
> Components: Security, SQL
> Reporter: Dag H. Wanvik
> Assignee: Dag H. Wanvik
> Fix For: 10.4.0.0
>
> Attachments: DERBY-3137-2.diff, DERBY-3137-2.stat, DERBY-3137-2.txt,
> DERBY-3137-uuid.diff, DERBY-3137-uuid.stat, DERBY-3137.diff, DERBY-3137.diff,
> DERBY-3137.stat, DERBY-3137.txt
>
>
> As a next step after adding support for the roles syntax, I intend to
> make a patch which implements catalog support for roles,
> cf. SYS.SYSROLES described in the specification (attached to
> DERBY-2207). Also the patch should tie this support up to the parser
> support, so the role statements can be executed. Any privileges
> granted to roles would still have no effect at run-time.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
