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 22:41:54 UTC
[jira] Created: (HIVE-1067) CREATE VIEW followup: impose casts on
view result columns if underlying column types change
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.
[jira] Commented: (HIVE-1067) CREATE VIEW followup: impose casts
on view result columns if underlying column types change
Posted by "John Sichi (JIRA)" <ji...@apache.org>.
[ 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.