You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hive.apache.org by "John Sichi (JIRA)" <ji...@apache.org> on 2010/01/20 23:05:54 UTC

[jira] Commented: (HIVE-1070) CREATE VIEW followup: add support for column-aliasing on subselect and use it when storing view definition with column renaming

    [ https://issues.apache.org/jira/browse/HIVE-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803015#action_12803015 ] 

John Sichi commented on HIVE-1070:
----------------------------------

This is a generically useful feature as well, independent of views.


> CREATE VIEW followup:  add support for column-aliasing on subselect and use it when storing view definition with column renaming
> --------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: HIVE-1070
>                 URL: https://issues.apache.org/jira/browse/HIVE-1070
>             Project: Hadoop Hive
>          Issue Type: Improvement
>          Components: Query Processor
>    Affects Versions: 0.6.0
>            Reporter: John Sichi
>            Assignee: John Sichi
>             Fix For: 0.6.0
>
>
> Copied from the original comment:
> If you do CREATE VIEW v(x,y) AS SELECT a+1,b+2 FROM t
> then we'll store the expanded view def as SELECT `_c0` AS `x`,`_c1` AS `y` FROM (SELECT `t`.`a`+1,`t`.`b`+2 FROM `t`) `v`
> As a result, if hive ever changes its convention for generating anonymous expression names (_c0, _c1, ...), such stored view definitions will break.
> The only way I can think of to avoid this is to implement SQL:200n's column-alias-by-position construct , e.g.
> (SELECT `t`.`a`+1,`t`.`b`+2 FROM `t`) AS `v`(`x`,`y`)
> (similar to what was done for LATERAL VIEW).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.