[
https://issues.apache.org/jira/browse/CALCITE-6309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825850#comment-17825850
]
James Duong commented on CALCITE-6309:
--------------------------------------
Thanks. Yes we can do that.
I have been investigating and found that flags differ a for different libraries
and often are outside of the capabilities of java.util.regex. What we currently
have in RegexFunction.makeRegexpFlags:
|| ||Java||
|i|case-insensitive|
|c|case-sensitive|
|n|dot includes newline characters|
|m|multiline|
* MySQL's flags are the same as the above table, except we need to add 'u' ->
UNIX_LINES
* Oracle is the same as the above table, except it has an extra 'x' option
which means ignore whitespace.
* PostgreSQL has both 'm' and 'n' mean multi-line instead of n mean dot
includes newline characters. PG has 's' mean dot includes newline characters.
PG also has 'p' (partial newline), 'w' mean inverse partial newline, 'x' mean
expanded syntax, and 't' mean tight syntax. None of those 4 flags have a
corresponding Pattern flag.
Currently unrecognized flags would cause makeRegexpFlags() throw an exception –
would that cause validation failures or simply prevent constant folding or
other optimizations that require function execution? For cases where different
libraries have two valid interpretations of the same set of flags, is the right
approach to provide separate implementations for each library?
> Add REGEXP_LIKE function (enabled in Postgres library)
> ------------------------------------------------------
>
> Key: CALCITE-6309
> URL: https://issues.apache.org/jira/browse/CALCITE-6309
> Project: Calcite
> Issue Type: Sub-task
> Reporter: James Duong
> Priority: Minor
> Labels: pull-request-available
>
> * The Spark version of this is being implemented in CALCITE-6278
> * The PostgreSQL version requires supporting a 3-arg version that takes in
> flags.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
