[
https://issues.apache.org/jira/browse/DERBY-5747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13269575#comment-13269575
]
Rick Hillegas commented on DERBY-5747:
--------------------------------------
Thanks for thinking about this issue, Dag. I agree that the reference material
should say that SYSCS_DROP_USER drops credentials and does not drop the
authorization id itself.
Would it be less confusing if we renamed some of the NATIVE procedures:
SYSCS_CREATE_PASSWORD
SYSCS_DROP_PASSWORD
rather than
SYSCS_CREATE_USER
SYSCS_DROP_USER
The alternative names might set more reasonable expectations.
Thanks,
-Rick
> Native user authentication: Docs do not describe what happens to schema and
> its SQL objects on SYSCS_UTIL.SYSCS_DROP_USER call
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5747
> URL: https://issues.apache.org/jira/browse/DERBY-5747
> Project: Derby
> Issue Type: Bug
> Components: Documentation, Services
> Affects Versions: 10.9.0.0
> Reporter: Dag H. Wanvik
> Attachments: repro2.sh
>
>
> Currently, the schema and the objects remain after the user is dropped, cf.
> repro2.sh attached.
> The authorization id of the schema of the dropped user is still that id
> (dangling) after DROP.
> Perhaps ownership should revert to the DBO when a user is dropped, or should
> DROP USER do a cascade delete?
> There is no way currently to change the ownership of the schema to another
> user.
> At the very least we should document what happens.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
