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] Assigned: (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:all-tabpanel ]
John Sichi reassigned HIVE-1070:
--------------------------------
Assignee: John Sichi
> 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.