[
https://issues.apache.org/jira/browse/CASSANDRA-9892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14651728#comment-14651728
]
Sam Tunnicliffe commented on CASSANDRA-9892:
--------------------------------------------
Ok, so those are 3 options/suggestions for the same thing (the syntax to enable
a role to create untrusted functions)? I would still say that the last one
reads as something related to changing the status of an existing function
because it doesn't refer to creation. Of the first 2 suggestions, I'd choose
the more explicit {{GRANT CREATE TRUSTED FUNCTION TO ...}}, the earlier comment
about the Permission name itself (aside from the CQL syntax) still stands
though - {{TRUSTED}} is incongruous with the existing permissions.
> Add support for unsandboxed UDF
> -------------------------------
>
> Key: CASSANDRA-9892
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9892
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Jonathan Ellis
> Assignee: Robert Stupp
> Priority: Minor
>
> From discussion on CASSANDRA-9402,
> The approach postgresql takes is to distinguish between "trusted" (sandboxed)
> and "untrusted" (anything goes) UDF languages.
> Creating an untrusted language always requires superuser mode. Once that is
> done, creating functions in it requires nothing special.
> Personally I would be fine with this approach, but I think it would be more
> useful to have the extra permission on creating the function, and also
> wouldn't require adding explicit CREATE LANGUAGE.
> So I'd suggest just providing different CQL permissions for trusted and
> untrusted, i.e. if you have CREATE FUNCTION permission that allows you to
> create sandboxed UDF, but you can only create unsandboxed if you have CREATE
> UNTRUSTED.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
