[
https://issues.apache.org/jira/browse/CALCITE-6301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17824124#comment-17824124
]
Alessandro Solimando commented on CALCITE-6301:
-----------------------------------------------
Thanks [~oliverlee], it's clear now with the updated example.
One question I still have is under what circumstances .
I have seen similar asks in the past for "must-filter" to force users to write
queries that could leverage indexes or partitioning, but I am having a
hard-time seeing how the "bypass-list" would come to rescue.
Could you sketch a use-case where the "bypass-list" would be helpful?
Just to be clear, I have nothing against this improvement, just curious to
understand the rationale behind it.
> Extend ‘Must-filter’ columns to support a conditional bypass list
> -----------------------------------------------------------------
>
> Key: CALCITE-6301
> URL: https://issues.apache.org/jira/browse/CALCITE-6301
> Project: Calcite
> Issue Type: Improvement
> Reporter: Oliver Lee
> Assignee: Oliver Lee
> Priority: Major
>
> In CALCITE-6219 we introduced SemanticTable, where tables that implement this
> interface can define fields to be ‘must-filter’, and a query without those
> filters in any of its WHERE or HAVING clauses, it will throw a validation
> error.
>
> I would like to extend this functionality to support a by-pass list of fields
> such that if any field from this secondary list is present in a WHERE /
> HAVING clause, then the must-filter fields can be ignored and will not raise
> an exception if not filtered on.
>
> Ex.
>
> EMP table specifies the following:
> Must-filter-fields: [EMPNO, DEPTNO]
> Bypass-fields: [ENAME, SALARY]
>
>
> SELECT * FROM EMP WHERE EMPNO = 1 and DEPTNO = 2 -> No error
> SELECT * FROM EMP WHERE EMPNO = 1 -> Error
> SELECT * FROM EMP WHERE EMPNO = 1 and ENAME = ’name’ -> No error
> SELECT * FROM EMP WHERE ENAME = ’name’ -> No error
> SELECT * FROM EMP WHERE SALARY > 10 -> No error
>
>
>
> Again, special considerations are for handling
>
> * Joins
> * CTEs
> * Subqueries
>
>
> And a similar exhaustive suite of tests like the one for CALCITE-6219 should
> be employed
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
