[
https://issues.apache.org/jira/browse/CALCITE-7244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18033026#comment-18033026
]
Steve Carlin commented on CALCITE-7244:
---------------------------------------
Ok, as I think about it more: I suppose "strict" isn't what I want at all. As
I looked at the code some more, "strict" didn't mean what I thought it meant.
It's only meant for a value to type check. It would prolly be a bad idea to
allow strict as an option.
What i really needed was to have VARCHAR be an allowable type, but I guess I
can understand the restrictions since the types aren't the same because of
trailing spaces.
I have yet another solution, one I tried at one point and hit a wall.
The class currently has a package protected constructor. Would you object to
changing this to "protected"?
> 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)
