[
https://issues.apache.org/jira/browse/CASSANDRA-8303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14273468#comment-14273468
]
Sylvain Lebresne commented on CASSANDRA-8303:
---------------------------------------------
bq. FTR, I'm not advocating this syntax yet as the version suggested by Aleksey
is certainly more SQL-ish, but just wanted to put it up for discussion
I don't yet have a definitive opinion on this either, but while the fact that
Aleksey's suggestion doesn't add any new concept is seducing, I do also suspect
that treating this as restrictions of other permissions might be clearer
conceptually and more future proof (it's more clear to me what happen when we
add new permission in the resctriction-version than if {{SELECT}} is just an
alias for a bunch of permissions. And syntax-wise, something like {{GRANT
INDEXING ON}} could become a problem if we ever allow the use of index in
updates (which I don't want to do but my point is just that future proofing
everything int the syntax might turn uglier than with Sam's {{WITH
RESTRICTION}} alternative)).
bq. I'd question whether UNPREPARED_STATEMENTS was really necessary
I agree that it's probably less useful than other restrictions, but I can see
it as useful for large organizations that want to enforce this easily. And
since it seems easy enough to include and without any real downside, I'd be
personally keen on including it from the start.
> Provide "strict mode" for CQL Queries
> -------------------------------------
>
> Key: CASSANDRA-8303
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8303
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Anupam Arora
> Fix For: 3.0
>
>
> Please provide a "strict mode" option in cassandra that will kick out any CQL
> queries that are expensive, e.g. any query with ALLOWS FILTERING,
> multi-partition queries, secondary index queries, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
