[
https://issues.apache.org/jira/browse/CALCITE-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15904108#comment-15904108
]
Julian Hyde commented on CALCITE-1684:
--------------------------------------
I have modified the patch to use -1. This has the nice effect that if the user
writes "VARCHAR" then it un-parses as "VARCHAR" because we store -1 meaning
"unspecified", whereas with [~kliew]'s current change it un-parses as
"VARCHAR(2147483647)".
Also note that Calcite's default max precision for VARCHAR is 65,536. But that
can be overridden in RelDataTypeSystem, and maybe Phoenix does that already.
In my modified patch, if you concatenate two strings and their combined length
exceeds the maximum precision, then the result type will have precision
"unspecified".
Here is my proposed change:
https://github.com/julianhyde/calcite/commit/52c58b1ec68660ee9e9e084472b16ff6ec46d1f1.
Please review.
> Set the precision for VARCHAR and VARBINARY to the maximum value when not
> specified
> -----------------------------------------------------------------------------------
>
> Key: CALCITE-1684
> URL: https://issues.apache.org/jira/browse/CALCITE-1684
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.11.0
> Reporter: Kevin Liew
> Assignee: Julian Hyde
> Priority: Minor
>
> The behavior for Calcite (and SQL Server) is to set {{VARCHAR}} precision to
> {{1}} when not specified whereas Phoenix sets the max integer value of
> {{2147483647}}.
> It doesn't really make sense to create a {{VARCHAR}} for a max length of
> {{1}} (it takes more bytes to store the length of each row than the actual
> value) and it shouldn't be the default behavior. I think we should adopt the
> Phoenix behavior. Do we need to make this configurable via SqlConformance or
> other?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
