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)