[
https://issues.apache.org/jira/browse/CALCITE-5677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717248#comment-17717248
]
Julian Hyde commented on CALCITE-5677:
--------------------------------------
[~dmsysolyatin]I’m sure there is one DB that does not support it. Or does the
wrong thing when the offset argument is zero or negative.
So we’d do better to invest our time in the test suite - automatically run the
generated SQL against each supported dialect and make sure the results are
correct.
[~tanclary], never start a summary with “fix”.
> Fix unparsing for BigQuery SUBSTR
> ---------------------------------
>
> Key: CALCITE-5677
> URL: https://issues.apache.org/jira/browse/CALCITE-5677
> Project: Calcite
> Issue Type: Bug
> Reporter: Tanner Clary
> Assignee: Tanner Clary
> Priority: Major
> Labels: pull-request-available
>
> BigQuery's {{SUBSTR(value, position[, length])}} function currently gets
> translated to the standard {{SUBSTRING(value FROM position[ FOR length])]}.
> BigQuery expects the arguments to be comma-separated rather than the use of
> the {{FROM}} and {{FOR}} keywords.
> EXAMPLE: {{SUBSTR('hello', 2)}} would get translated to {{SUBSTRING('hello'
> FROM 2)}} which BigQuery does not recognize.
> Hive addresses this issue by adding onto {{HiveSqlDialect#unparseCall}}
> method. I believe BigQuery should do something similar to avoid this
> incorrect translation. The docs for the {{SUBSTR}} (and alias {{SUBSTRING}})
> function may be found
> [here|https://cloud.google.com/bigquery/docs/reference/standard-sql/string_functions#substr].
> I will open a PR shortly that implements my suggestion and adds a couple of
> tests as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
