[ https://issues.apache.org/jira/browse/CALCITE-4510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17290783#comment-17290783 ]
Ruben Q L commented on CALCITE-4510: ------------------------------------ Thanks for the explanation, [~fan_li_ya]. I agree removing this hard-coded " NOT NULL" that is all around the place and centralize it in a single constant is a good idea (plus it solves your problem with user-defined type systems). Searching the code, it seems the PR could go a bit further and do the replacement in other classes too: - RelDatatypeImpl (already covered in the initial PR) - RexLiteral (already covered in the initial PR) - SqlTypeUtil#equalSansNullability - RelOptUtil#TypeDumper#accept (x2) And even in some tests classes: - SqlTests#getTypeString - SqlOperatorBaseTest (x4): checkCastToApproxOkay, checkCastToStringOkay, checkCastToScalarOkay, assertSubFunReturns - CalciteAssert#typeString - RexProgramTestBase#assertNode - RexProgramTest#assertTypeAndToString WDYT? > Weird digests for literals with some user defined types > ------------------------------------------------------- > > Key: CALCITE-4510 > URL: https://issues.apache.org/jira/browse/CALCITE-4510 > Project: Calcite > Issue Type: Bug > Components: core > Reporter: Liya Fan > Assignee: Liya Fan > Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > We find weird literals for some user defined non-nullable types. Some > investigation shows that the problem lies in the {{RexLiteral#toJavaString}} > method. > In particular, it checks the type string suffix with an 8-character string: > {noformat} > if (!fullTypeString.endsWith("NOT NULL")) { > {noformat} > However, it trims the last 9 characters from the end of the string: > {noformat} > sb.append(fullTypeString, 0, fullTypeString.length() - 9); > {noformat} -- This message was sent by Atlassian Jira (v8.3.4#803005)