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

Chiran Ravani updated HIVE-22641:
---------------------------------
    Description: 
In Hive 1.2.1 and 2.0 while displaying columns for a table, it used to return 
in same order as it was created. for example

{code}
create table col_order_test(server_name string, task_name string, 
partition_name string, start_time string, end_time string, table_owner string, 
table_name string) stored as orc;
show columns in col_order_test;

+-----------------+--+
|      field      |
+-----------------+--+
| server_name     |
| task_name       |
| partition_name  |
| start_time      |
| end_time        |
| table_owner     |
| table_name      |
+-----------------+--+
{code}

For Hive 3 columns are returned in sorted order for the same query, below is 
output.
{code}
create table col_order_test(server_name string, task_name string, 
partition_name string, start_time string, end_time string, table_owner string, 
table_name string) stored as orc;
show columns in col_order_test;

+-----------------+
|      field      |
+-----------------+
| end_time        |
| partition_name  |
| server_name     |
| start_time      |
| table_name      |
| table_owner     |
| task_name       |
+-----------------+
{code}

Above behavior looks to be changed with the introduction of search column 
feature as part of Jira [HIVE-18373 
|https://issues.apache.org/jira/browse/HIVE-18373]

This behavior change can cause an existing process to fail in a few 
environments, for example, code to generate the INSERT OVERWRITE in a different 
manner,  which may result in query failure.

I would like to request a community if we can improve the Jira [HIVE-18373 
|https://issues.apache.org/jira/browse/HIVE-18373] by returning column order 
same as it was created if the search pattern provided by the user is null.

Attaching patch with the change.

  was:
In Hive 1.2.1 and 2.0 while displaying columns for a table, it used to return 
in same order as it was created. for example

{code}
create table col_order_test(server_name string, task_name string, 
partition_name string, start_time string, end_time string, table_owner string, 
table_name string) stored as orc;
show columns in col_order_test;

+-----------------+--+
|      field      |
+-----------------+--+
| server_name     |
| task_name       |
| partition_name  |
| start_time      |
| end_time        |
| table_owner     |
| table_name      |
+-----------------+--+
{code}

For Hive 3 columns are returned in sorted order for the same query, below is 
output.
{code}
create table col_order_test(server_name string, task_name string, 
partition_name string, start_time string, end_time string, table_owner string, 
table_name string) stored as orc;
show columns in col_order_test;

+-----------------+
|      field      |
+-----------------+
| end_time        |
| partition_name  |
| server_name     |
| start_time      |
| table_name      |
| table_owner     |
| task_name       |
+-----------------+
{code}

Above behavior looks to be changed with the introduction of search column 
feature as part of Jira [HIVE-18373 
|https://issues.apache.org/jira/browse/HIVE-18373]

This behavior change can cause existing process to fail setup in a few 
environments, for example: code to generate the INSERT OVERWRITE in a different 
manner,  which may result in query failure.

I would like to request a community if we can improve the Jira [HIVE-18373 
|https://issues.apache.org/jira/browse/HIVE-18373] by returning column order 
same as it was created if the search pattern provided by the user is null.

Attaching patch with the change.


> Columns returned in sorted order when show columns query is run with no 
> search pattern.
> ---------------------------------------------------------------------------------------
>
>                 Key: HIVE-22641
>                 URL: https://issues.apache.org/jira/browse/HIVE-22641
>             Project: Hive
>          Issue Type: Improvement
>          Components: Hive, HiveServer2
>    Affects Versions: 3.1.0
>            Reporter: Chiran Ravani
>            Assignee: Chiran Ravani
>            Priority: Major
>         Attachments: HIVE-22641.patch
>
>
> In Hive 1.2.1 and 2.0 while displaying columns for a table, it used to return 
> in same order as it was created. for example
> {code}
> create table col_order_test(server_name string, task_name string, 
> partition_name string, start_time string, end_time string, table_owner 
> string, table_name string) stored as orc;
> show columns in col_order_test;
> +-----------------+--+
> |      field      |
> +-----------------+--+
> | server_name     |
> | task_name       |
> | partition_name  |
> | start_time      |
> | end_time        |
> | table_owner     |
> | table_name      |
> +-----------------+--+
> {code}
> For Hive 3 columns are returned in sorted order for the same query, below is 
> output.
> {code}
> create table col_order_test(server_name string, task_name string, 
> partition_name string, start_time string, end_time string, table_owner 
> string, table_name string) stored as orc;
> show columns in col_order_test;
> +-----------------+
> |      field      |
> +-----------------+
> | end_time        |
> | partition_name  |
> | server_name     |
> | start_time      |
> | table_name      |
> | table_owner     |
> | task_name       |
> +-----------------+
> {code}
> Above behavior looks to be changed with the introduction of search column 
> feature as part of Jira [HIVE-18373 
> |https://issues.apache.org/jira/browse/HIVE-18373]
> This behavior change can cause an existing process to fail in a few 
> environments, for example, code to generate the INSERT OVERWRITE in a 
> different manner,  which may result in query failure.
> I would like to request a community if we can improve the Jira [HIVE-18373 
> |https://issues.apache.org/jira/browse/HIVE-18373] by returning column order 
> same as it was created if the search pattern provided by the user is null.
> Attaching patch with the change.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to