[
https://issues.apache.org/jira/browse/CALCITE-7244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18032984#comment-18032984
]
Steve Carlin commented on CALCITE-7244:
---------------------------------------
Just a little background: I've wanted this for over a year and always tried to
work around issues because I know how hard it is to get things committed into
Calcite. In fact, I did work around this issue, but in a different way, as was
mentioned earlier in this thread, and it works fine. But making this change
makes my code quite a bit simpler, so I figured I'd give it a try and create
this Jira request. There may be others who have this problem as well and just
haven't complained about it like me until now, but obviously I can't speak to
that.
So you got me thinking about this a lot today, but I don't think I can use the
things you suggest. Perhaps there is another solution though, I need to think
about it more. And perhaps there is a solution without changing Calcite, but
as I'm writing this, I only have one solution that I'd like to avoid.
I see that RexLiteral has a constructor that takes both a RelDataType and a
SqlTypeName. This would work wonderfully for me! If I could create a
RexLiteral with a RelDataType that has a VARCHAR and pass in the SqlTypeName as
CHAR, welp, that prolly solves my problem too.
The problems I see though are:
a) RexLiteral is inaccessible to me, which is as designed and a good thing, so
I wouldn't want to change that.
b) makeLIteral only takes a RelDataType and when it creates the RexLiteral, it
is explicitly tied to the SqlTypeName as shown with this statement:
[https://github.com/apache/calcite/blob/main/core/src/main/java/org/apache/calcite/rex/RexBuilder.java#L2073]
So my RexLiteral is always gonna have a RelDataType.SqlTypeName of CHAR and a
SqlTypeName of CHAR. I don't think I can solve this with my own RexBuilder
unless I put it inside the same package as "calcite.rex" which is doable but
I'd get comments on my code review on my side if I did that. And that
makeLiteral would also have a lot of duplicated code from Calcite.
Or maybe you mean a broader change where I pass in a RelDataType of char, but
it is a specific type made for literals? That would make SqlTypeName useless
for me in my code and I rely on that a lot in what I have developed already.
Maybe I'd have to come up with my own enum and make full use of
RelDataTypeSystem? Seems like a lot of hoops to jump through on this and I'd
prolly just stick to what I already have.
Another potential solution is allowing an SqlTypeName to be passed in with
makeLiteral? Heh, that might even be worse than the "strict" option.
I would also add that we have precedence for different SqlTypeNames to be
supported for a literal, e.g. 2 can have the SqlTypeName of TINYINT or INTEGER
But if you reject this because you think there's a way I can do this using type
system, so be it. As I mentioned, I'm only asking this because it makes my
code a lot simpler, but I already have a solution.
Thanks!
> 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)
