[
https://issues.apache.org/jira/browse/CALCITE-7267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18035501#comment-18035501
]
Yu Xu edited comment on CALCITE-7267 at 11/5/25 3:33 AM:
---------------------------------------------------------
I have modified the current Jira content and changed the title to "CHAR_LENGTH
function is not recognized in Oracle dialogue" based on the previous situation.
Then I tried implementing the suggestion, such as uniformly handling functions
in the SqlDialect base class, but needed to maintain a mapping with a structure
similar to Map<Function, Set<Dialect>>, and had a few issues to report
# From a unified architecture perspective, if the number of newly added
function conversions continues to grow, the logic of the parent class Dialect
will become increasingly bloated, while also needing to handle the logic of all
subclasses;
# Different dialects may have Function A—>Implementation1 and Function
A—>Implementation2, leading to increased complexity in logic management;
# The readability of the code may be compromised to some extent. If others
encounter similar dialect issues and wish to modify them, they may need to
first understand this logic, which could be less convenient than the current
approach;
# Implementing separately within each dialect subclass may appear redundant,
but it offers greater flexibility when addressing the aforementioned issues. I
understand that this approach has been consistently used to handle function
compatibility problems for precisely this reason.
So my suggestion is similar to [~jensen] . Is the current PR implementation OK?
[~julianhyde]
was (Author: JIRAUSER307770):
I tried implementing the suggestion, such as uniformly handling functions in
the SqlDialect base class, but needed to maintain a mapping with a structure
similar to Map<Function, Set<Dialect>>, and had a few issues to report
# From a unified architecture perspective, if the number of newly added
function conversions continues to grow, the logic of the parent class Dialect
will become increasingly bloated, while also needing to handle the logic of all
subclasses;
# Different dialects may have Function A—>Implementation1 and Function
A—>Implementation2, leading to increased complexity in logic management;
# The readability of the code may be compromised to some extent. If others
encounter similar dialect issues and wish to modify them, they may need to
first understand this logic, which could be less convenient than the current
approach;
# Implementing separately within each dialect subclass may appear redundant,
but it offers greater flexibility when addressing the aforementioned issues. I
understand that this approach has been consistently used to handle function
compatibility problems for precisely this reason.
So my suggestion is similar to [~jensen] . Is the current PR implementation OK?
[~julianhyde]
> CHAR_LENGTH function is not recognized in Oracle dialect
> --------------------------------------------------------
>
> Key: CALCITE-7267
> URL: https://issues.apache.org/jira/browse/CALCITE-7267
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.41.0
> Reporter: Yu Xu
> Assignee: Yu Xu
> Priority: Minor
> Labels: pull-request-available
> Fix For: 1.42.0
>
>
> *CHAR_LENGTH* function is not support for Oracle, but LENGTH is supported.
> refer:
> [https://docs.oracle.com/en/database/oracle/oracle-database/18/sqlrf/LENGTH.html]
> execute sql1
> {code:java}
> select CHAR_LENGTH('aaa') {code}
> error message report:
> {code:java}
> ORA-00904: "CHAR_LENGTH": invalid identifier
> https://docs.oracle.com/error-help/db/ora-00904/
> 00904. 00000 - "%s: invalid identifier"
> *Cause: The identifier or column name entered was invalid.
> *Action: Ensure the following
> Error at Line: 1 Column: 6 {code}
>
> execute sql2
> {code:java}
> select LENGTH('aaa') {code}
> then result is ok:
> {code:java}
> 3
> {code}
> so in Oracle dialect, CHAR_LENGTH should convert to LENGTH function. such as
> other dialect presto https://issues.apache.org/jira/browse/CALCITE-6643
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
