You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Zhen Chen (Jira)" <ji...@apache.org> on 2025/10/27 01:25:00 UTC
[jira] [Comment Edited] (CALCITE-7244) Support for VARCHAR RexLiteral
[ https://issues.apache.org/jira/browse/CALCITE-7244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18033096#comment-18033096 ]
Zhen Chen edited comment on CALCITE-7244 at 10/27/25 1:24 AM:
--------------------------------------------------------------
We also encountered the issue mentioned by [~scarlin] when using Calcite. I understand that the current behavior should be something that the database type system needs to be compatible with. However, the point raised by this Jira is indeed a practical requirement, because not all database systems are that mature, or they may not focus on this difference. Although I agree that inferring a string as a CHAR type is a reasonable behavior, in certain cases, such as in an IN clause, strings of different lengths are aligned to the longest CHAR type. For example, {{{}x in ('a', 'bb', 'ccc'){}}}would be processed as {{x in ('a }}{{{}', 'bb ', 'ccc'){}}}. I think keeping {{{}x in ('a', 'bb', 'ccc'){}}}unchanged(As Jira suggested, it would be better to make it VARCHAR) could also be a good alternative. Although I don't have as strong a need as [~scarlin] does, I would be happy to use such a configuration if it were available.
was (Author: jensen):
We also encountered the issue mentioned by [~scarlin] when using Calcite. I understand that the current behavior should be something that the database type system needs to be compatible with. However, the point raised by this Jira is indeed a practical requirement, because not all database systems are that mature, or they may not focus on this difference. Although I agree that inferring a string as a CHAR type is a reasonable behavior, in certain cases, such as in an IN clause, strings of different lengths are aligned to the longest CHAR type. For example, {{{}x in ('a', 'bb', 'ccc'){}}}would be processed as {{x in ('a}}{{ }}{{}}{{ }}{{{}', 'bb ', 'ccc'){}}}. I think keeping {{{}x in ('a', 'bb', 'ccc'){}}}unchanged(As Jira suggested, it would be better to make it VARCHAR) could also be a good alternative. Although I don't have as strong a need as [~scarlin] does, I would be happy to use such a configuration if it were available.
> Support for VARCHAR RexLiteral
> ------------------------------
>
> Key: CALCITE-7244
> URL: https://issues.apache.org/jira/browse/CALCITE-7244
> Project: Calcite
> Issue Type: Wish
> Reporter: Steve Carlin
> Priority: Major
>
> Oh, the powers that be:
> I would be oh so happy if we can remove this line of code:
> [https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/rex/RexLiteral.java#L381|https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/rex/RexLiteral.java#L374]
> ...or at least allow a character RexLiteral to be created with type VARCHAR
> You see, when I do a CTAS statement with a "select 'hello'", it creates a STRING datatype, not a CHAR datatype in my database. Since I currently can't create a RexLiteral VARCHAR, I have to introduce a CAST around the literal, and I can't do this until RelNode/RexNode time. Even worse, when I have a Values RelNode, I have to create a Project on top of the Values with a cast.
> Please, oh please, take this into consideration and allow this. It would make my code a lot simpler.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)