You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Yu Xu (Jira)" <ji...@apache.org> on 2025/11/05 03:31:00 UTC
[jira] [Comment Edited] (CALCITE-7267) CHAR_LENGTH function is not recognized in Oracle dialect
[ 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:30 AM:
---------------------------------------------------------
I tried implementing the suggestion, such as uniformly handling functions in the SqlDialect base class, but needed to maintain a list 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 list with a structure similar to Map<Function, Set<Dialect>>, and had a few issues to report
1. 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;
2. Different dialects may have Function A—>Implementation1 and Function A—>Implementation2, leading to increased complexity in logic management;
3. 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;
4. 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)