[
https://issues.apache.org/jira/browse/CALCITE-7244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18032953#comment-18032953
]
Steve Carlin commented on CALCITE-7244:
---------------------------------------
Ok, before I publish a PR...I started looking at this and I'm running into an
interesting issue. I'm worried you may think I'm over-engineering this, so I
want to present it here first (or should I present it on the dev list? I
started to write something up, and the email will be quite large if I do it
that way for what seemingly is a small issue).
My proposal:
I'd like to add the following method into RexBuilder
{code:java}
RexLiteral makeLiteral(Object value, RelDataType type, boolean allowCast,
boolean trim, StrictMode strictMode);{code}
My first instinct was to add just a "boolean strict", but I don't think that
works very well.
The problem is this: you can call makeLiteral like this:
{code:java}
builder.makeLiteral("foobar", varcharType, false, false){code}
...since the allowCast is false, it ignores the varcharType. But it doesn't
throw an exception. It simply returns the RexLiteral back as type CHAR.
So that really is a third mode of "strictness", and it's the default mode if we
want to retain backward compatibility. So the 3 modes of behavior I see are:
1) NON_STRICT - ignores the allowCast option. This will always return a
RexLiteral, if the non-strict compatibility allows it.
2) STRICT_NO_FAIL: If allowCast is set true, creates a cast if the strict value
doesn't match the type. If allowCast is set false, it will coerce type to
appropriate strict value. This is the default for backward compatibility.
3) STRICT: If allowCast is set to true, creates the cast if the strict value
doesn't match the type. If allowCast is set false, throw an exception.
I almost feel like an enum of StrictMode is too much engineering? But due to
this backward compatibility issue, I think it's the right thing to do.
Thoughts?
> 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)
