db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3137) SQL roles: add catalog support
Date Wed, 24 Sep 2008 13:42:44 GMT

     [ 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.


Mime
View raw message