[
https://issues.apache.org/jira/browse/PHOENIX-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13935302#comment-13935302
]
James Taylor commented on PHOENIX-853:
--------------------------------------
I'd vote for the latter, (LPAREN l=NUMBER (COMMA s=NUMBER)? RPAREN), as not all
of the options in ColumnDef apply for cast (though I suppose you could argue
they should). The one that doesn't is the array length. We currently don't use
that, but we do persist it in our metadata and may use it in the future.
When you add it, take a look at PArrayDataType.coerceBytes() and make sure it's
doing the right thing. For the VARCHAR case it's not going to make a lot of
difference, but for the CHAR case it might. For this case, we infer the max
length based on the value with the max length. This would likely change that -
maybe we'd use this value instead if it was bigger than that.
> Support CAST(x as varchar(length)) syntax
> -----------------------------------------
>
> Key: PHOENIX-853
> URL: https://issues.apache.org/jira/browse/PHOENIX-853
> Project: Phoenix
> Issue Type: Improvement
> Reporter: Bruno Dumon
>
> I would like Phoenix to recognize casts to varchars that specify lengths,
> e.g. cast(x as varchar(10)). It is not an immediate goal to enforce the
> length, but at least to recongize the syntax.
> (the reason I'm running into this is because I have sql generated by Optiq
> which uses these kinds of constructs)
> I can easily hack the grammar to add this to the CAST grammar, but then I
> realize that the data type specification one can put in a cast is the same as
> what you can put in a column definition. Therefore, it would make more sense
> to introduce a separate rule to parse the data type and reuse that in the
> cast and column_def rules.
> For arrays, the specification is currently not consistent:
> * in column_def it is: ar=ARRAY? (lsq=LSQUARE (a=NUMBER)? RSQUARE)?
> * in casts it is: ar=(ARRAY | (LSQUARE RSQUARE))? RPAREN
> I assume this is not on purpose and can be aligned.
> So in summary, what I'd like to do:
> * introduce some object to hold the data type information, e.g.
> "DataTypeDef", which splits of the pure data type parts from ColumnDef,
> ColumnDef would then contain a DataTypeDef
> * introduce a separate parser rule to match the data type specification, and
> which returns this new DataTypeDef object
> * reuse this parser rule in the column_def and cast rules
> * functionally, casts would stay the same for now
> Alternatively, I can just add "(LPAREN l=NUMBER (COMMA s=NUMBER)? RPAREN)?"
> to the cast rule and be done with it.
> WDYT?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
