[ 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)