phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bruno Dumon (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (PHOENIX-853) Support CAST(x as varchar(length)) syntax
Date Mon, 17 Mar 2014 11:23:42 GMT

     [ https://issues.apache.org/jira/browse/PHOENIX-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Bruno Dumon updated PHOENIX-853:
--------------------------------

    Attachment: support-length-and-scale-in-cast.patch.txt

Attaching a patch which recognizes length and scale for cast in the grammar. It also passes
on the information to the CastParseNode, but there it stops. I've added some tests to QueryCompilerTest.

> 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
>         Attachments: support-length-and-scale-in-cast.patch.txt
>
>
> 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)

Mime
View raw message