[
https://issues.apache.org/jira/browse/CALCITE-7244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18034862#comment-18034862
]
Steve Carlin commented on CALCITE-7244:
---------------------------------------
So for the record from my side:
I totally get the purity argument. I like the way the code is structured and
do agree with you from a purity sense that this is the way it should be. I'm
always very careful about asks like this. And I was pretty sure it wouldn't be
accepted, and it wasn't.
But I also wear a practical engineering hat that sometimes sacrifices purity
when weighing all considerations.
You're asking me to weeks and weeks of time, something that I am almost sure
will be hard to get in because it is not standard SQL, something that a few,
but maybe not many people need, because you are worried about an infinitesimal
hole I'm poking in one class, one which already exists in RexCall because that
class needed a child class. Because you are worried about a hypothetical case
that someone who has every right to extend your classes could theoretically
file a bug because they extended the class and didn't take the time to sort out
that their extended class was risky and that it might be a Calcite bug.
I have a workaround for my project to get this going. It's...pretty dang
messy, but it works. This slight hole poke would clean up my code a lot.
But here's a hypothetical as well... if I couldn't get the workaround going, I
would have been forced to make this ask. And with this rejection, if my
project was in the early phase, there's a good chance that I would have
abandoned trying to use Calcite in my project, anticipating the problems of
trying to get a feature like this in. This hypothetical person out there might
abandon their Calcite project because string literals cannot have the VARCHAR
type, something which I don't think is incredibly crazy.
I don't think the type system stuff helps me because I'm forced to have my
RelDataType.getSqlTypeName() be the same as the RexLiteral SqlTypeName, both of
which are passed into the constructor of RexLiteral. A RexCall cast doesn't
work because Values nodes only take RexLiterals, so I'm forced to create a
Project on top of a Values node (which is what I'm actually doing right now).
Anyway, that's my two cents. I'll live with my workaround and maybe eventually
get around to trying to submit a fuller feature in Calcite.
> 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)
