[
https://issues.apache.org/jira/browse/CALCITE-6120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde reassigned CALCITE-6120:
------------------------------------
Assignee: Julian Hyde
> Add MATCHES_FILTER function, to match on Looker-style filter expressions
> ------------------------------------------------------------------------
>
> Key: CALCITE-6120
> URL: https://issues.apache.org/jira/browse/CALCITE-6120
> Project: Calcite
> Issue Type: Improvement
> Reporter: Julian Hyde
> Assignee: Julian Hyde
> Priority: Major
>
> Add a MATCHES_FILTER function that returns whether an expression matches
> Looker-style filter expression. It would be enabled in only the BigQuery
> library (although it is not a function currently supported by BigQuery).
> Looker filters are strings that express ranges in a concise way that are easy
> to humans to write and understand, and not as error-prone as traditional SQL
> expressions. Think of them as a generalization of {{LIKE}} from strings to
> other data types such as DATE and INTEGER.
> Here is an example:
> {code}
> SELECT *
> FROM Emp
> WHERE MATCHES_FILTER(hiredate, 'last 3 months')
> {code}
> See the [filter expressions
> specification|https://cloud.google.com/looker/docs/filter-expressions].
> The implementation can be a wrapper around the
> [filtex|https://github.com/julianhyde/filtex] library that expands
> {{MATCHES_FILTER}} as a macro. The library parses filter expressions, and we
> convert its AST into a tree of RexNode. For example
> {{MATCHES_FILTER(hiredate, 'last 3 months')}} becomes a RexNode equivalent to
> {{hiredate BETWEEN current_date - interval 3 month AND current_date}}.
> The initial implementation would require the filter expression to be a
> constant (such as literal). This would ensure that filter expressions are
> only ever parsed at prepare time, not during execution of the query.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
