[
https://issues.apache.org/jira/browse/CALCITE-5979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17763215#comment-17763215
]
Tanner Clary edited comment on CALCITE-5979 at 9/8/23 6:40 PM:
---------------------------------------------------------------
I agree that it seems like a bit much to accommodate for what seems to be a
pretty small difference, but I also think it is hard to draw the line on what
warrants a new operator entry or not. For instance, {{FLOOR}} and {{SUBSTR}}
both have dialect-specific operators because the behavior varies across
dialects in one way or another (perhaps in return type, or unparsing syntax,
etc.). I can foresee a situation where we decide not to support this specific
behavior to avoid adding a new operator, and then somewhere down the line a bug
gets filed because someone is expecting this behavior to work because we say we
support BigQuery's functionality, and instead it fails. I only mention that
because I have introduced some of those bugs myself. Maybe that's overthinking
it a bit but it's worth keeping in mind I think.
I am also curious what would happen if this behavior was enabled for the other
dialects? Would it throw an unexpected error? Would it return the wrong
results? Would it change anything?
was (Author: JIRAUSER298151):
I agree that it seems like a bit much to accommodate for what seems to be a
pretty small difference, but I also think it is hard to draw the line on what
warrants a new operator entry or not. For instance, {{FLOOR}} and {{SUBSTR}}
both have dialect-specific operators because the behavior varies across
dialects in one way or another (perhaps in return type, or unparsing syntax,
etc.). I can foresee a situation where we decide not to support this specific
behavior to avoid adding a new operator, and then somewhere down the line a bug
gets filed because someone is expecting this behavior to work because we say we
support BigQuery's functionality, and instead it fails. I only mention that
because I have introduced some of those bugs myself. Maybe that's overthinking
it a bit but it's worth keeping in mind I think.
> Add REGEXP_REPLACE function (enabled in BigQuery library)
> ---------------------------------------------------------
>
> Key: CALCITE-5979
> URL: https://issues.apache.org/jira/browse/CALCITE-5979
> Project: Calcite
> Issue Type: Task
> Reporter: Jerin John
> Assignee: Jerin John
> Priority: Major
> Labels: pull-request-available
>
> Add support for [REGEXP_REPLACE
> |https://cloud.google.com/bigquery/docs/reference/standard-sql/string_functions#regexp_replace]
> function from BigQuery.
> *{{REGEXP_REPLACE(value, regexp, replacement)}}*
> Returns a STRING where all substrings of {{value}} that match regular
> expression {{regexp}} are replaced with {{{}replacement{}}}.
> backslashed-escaped digits (\1 to \9) can be used within the {{replacement}}
> argument to insert text matching the corresponding parenthesized group in the
> {{regexp}} pattern.
> Example (added one space between \ \ to override md formatting):
> {{SELECT REGEXP_REPLACE("abc'", "b(.)", "X\ \1") as result;}}
> |result|
> |aXc|
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
