hadoop-hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Sichi (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HIVE-1067) CREATE VIEW followup: impose casts on view result columns if underlying column types change
Date Wed, 20 Jan 2010 21:45:54 GMT

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

John Sichi commented on HIVE-1067:
----------------------------------

Assuming we want to go ahead with what was decided at the code review, I'll need to detect
the type difference when the view is expanded in a referencing select, and insert cast operators
accordingly.  This could be a bit of work (and implies that data conversion errors could be
introduced at runtime by the casts).

Alternately, we could leave it as is to get the MySQL behavior, except that we would need
to do something to make DESCRIBE consistent (this might best be done as part of support for
view dependency tracking).


> CREATE VIEW followup:  impose casts on view result columns if underlying column types
change
> --------------------------------------------------------------------------------------------
>
>                 Key: HIVE-1067
>                 URL: https://issues.apache.org/jira/browse/HIVE-1067
>             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
>
>
> Consider
> CREATE TABLE t(i INT);
> CREATE VIEW v AS SELECT i FROM t;
> ALTER TABLE t REPLACE COLUMNS (i STRING);
> SELECT i FROM v;
> What will be the result type for i in the final SELECT?
> Consensus at code review was that it should be INT (not STRING) since the CREATE VIEW
is supposed to freeze the metadata for the view's result schema.  Note that SQL:2008 ALTER
COLUMN SET DATA TYPE doesn't cover this case, because it doesn't support changing the datatype
family.  For this case, MySQL produces VARCHAR rather than INT, and (consistently) DESCRIBE
v and INFORMATION_SCHEMA show VARCHAR as well, so either they are propagating the type change
in the catalog, or dynamically re-deriving it.

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


Mime
View raw message