[
https://issues.apache.org/jira/browse/DERBY-3137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dag H. Wanvik updated DERBY-3137:
---------------------------------
Attachment: DERBY-3137-setRoleNoCNF.stat
DERBY-3137-setRoleNoCNF.diff
Uploading DERBY-3137-setRoleNoCNF which:
- changes the behavior of SET ROLE ? to interpret the dynamic argument
as an undelimited SQL identifier. Up till now, it was interpreted as
an identifer in internal (case normal form), but this seems wrong
according to SQL 2003, section 18.3, GR3, cf discussion with Dan
earlier in this thread. A Java null value is no longer accepted as
an argument; "none" should be used also in the dynamic case. An
empty string or a null value will give identifer parse error
("XCXA0").
Also, section 18.3, GR2 calls for whitespace to be removed from the
string before interpreting it as an identifier. This is now also
performed.
- similarly changes the builtin function CURRENT_ROLE to now return a
delimited identifer if the role is set, making it "symmetrical" with
SET ROLE, that is, the output of CURRENT_ROLE can be used as input
to "SET ROLE ?". When the role is not set, CURRENT_ROLE returns
NULL, which can not be used as input to "SET ROLE ?", it now
requires the string "none". This seems to be what the standard
requires.
I'd appreciate the community's opinion on the following question:
the standard makes no requirement that the returned identifier be
delimited, allowing us to return an undelimited identifier in cases
where this is "safe". Does it add any value to do that or is it
better to always return it in delimited form?
- updated tests to new behavior.
Note that with this change, SET ROLE ? and CURRENT_ROLE behaves
differently from SET SCHEMA and CURRENT_SCHEMA respectively. They are
still in violation with the standard on this point.
Running regressions now.
> SQL roles: add catalog support
> ------------------------------
>
> Key: DERBY-3137
> URL: https://issues.apache.org/jira/browse/DERBY-3137
> Project: Derby
> Issue Type: Task
> Components: Security, SQL
> Reporter: Dag H. Wanvik
> Assignee: Dag H. Wanvik
> Fix For: 10.5.0.0
>
> Attachments: DERBY-3137-2.diff, DERBY-3137-2.stat, DERBY-3137-2.txt,
> DERBY-3137-ijfix.diff, DERBY-3137-ijfix.diff, DERBY-3137-ijfix.stat,
> DERBY-3137-ijfix.stat, DERBY-3137-rename-b.diff, DERBY-3137-rename-b.stat,
> DERBY-3137-rename.diff, DERBY-3137-rename.diff, DERBY-3137-rename.stat,
> DERBY-3137-rename.stat, DERBY-3137-setRoleNoCNF.diff,
> DERBY-3137-setRoleNoCNF.stat, DERBY-3137-uuid-2.diff, 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.
