[
https://issues.apache.org/jira/browse/DRILL-3860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) updated DRILL-3860:
------------------------------------------
Description:
At least when it appears in a SELECT list, a delimited identifier whose body
consists of a single asterisk ("{{`\*`}}") is not treated consistently with
other delimited identifiers (that is, specifying a column whose name matches
the body ("{{\*}}").)
For example, in the following, notice how in the first two queries, each select
list delimited identifier selects the one expected column, but in the third
query, instead of selecting the one expected column, it selected all columns
(list the regular "{{*}}" in the fourth query):
{noformat}
0: jdbc:drill:zk=local> SELECT `a` FROM (VALUES (1, 2, 3)) AS T(a, `.`, `*`);
+----+
| a |
+----+
| 1 |
+----+
1 row selected (0.132 seconds)
0: jdbc:drill:zk=local> SELECT `.` FROM (VALUES (1, 2, 3)) AS T(a, `.`, `*`);
+----+
| . |
+----+
| 2 |
+----+
1 row selected (0.152 seconds)
0: jdbc:drill:zk=local> SELECT `*` FROM (VALUES (1, 2, 3)) AS T(a, `.`, `*`);
+----+----+----+
| a | . | * |
+----+----+----+
| 1 | 2 | 3 |
+----+----+----+
1 row selected (0.136 seconds)
0: jdbc:drill:zk=local> SELECT * FROM (VALUES (1, 2, 3)) AS T(a, `.`, `*`);
+----+----+----+
| a | . | * |
+----+----+----+
| 1 | 2 | 3 |
+----+----+----+
1 row selected (0.128 seconds)
0: jdbc:drill:zk=local>
{noformat}
Although this acts the same as if the SQL parser treated the delimited
identifier {{`\*`}} as a plain asterisk token, that does not seem to be the
actual mechanism for this behavior. (The problem seems to be further
downstream.)
was:
At least when it appears in a SELECT list, a delimited identifier whose body
consists of a single asterisk ("{{`*`}}") is not treated consistently with
other delimited identifiers (that is, specifying a column whose name matches
the body ("{{*}}").)
For example, in the following, notice how in the first two queries, each select
list delimited identifier selects the one expected column, but in the third
query, instead of selecting the one expected column, it selected all columns
(list the regular "{{*}}" in the fourth query):
{noformat}
0: jdbc:drill:zk=local> SELECT `a` FROM (VALUES (1, 2, 3)) AS T(a, `.`, `*`);
+----+
| a |
+----+
| 1 |
+----+
1 row selected (0.132 seconds)
0: jdbc:drill:zk=local> SELECT `.` FROM (VALUES (1, 2, 3)) AS T(a, `.`, `*`);
+----+
| . |
+----+
| 2 |
+----+
1 row selected (0.152 seconds)
0: jdbc:drill:zk=local> SELECT `*` FROM (VALUES (1, 2, 3)) AS T(a, `.`, `*`);
+----+----+----+
| a | . | * |
+----+----+----+
| 1 | 2 | 3 |
+----+----+----+
1 row selected (0.136 seconds)
0: jdbc:drill:zk=local> SELECT * FROM (VALUES (1, 2, 3)) AS T(a, `.`, `*`);
+----+----+----+
| a | . | * |
+----+----+----+
| 1 | 2 | 3 |
+----+----+----+
1 row selected (0.128 seconds)
0: jdbc:drill:zk=local>
{noformat}
Although this acts the same as if the SQL parser treated the delimited
identifier {{`*`}} as a plain asterisk token, that does not seem to be the
actual mechanism for this behavior. (The problem seems to be further
downstream.)
> Delimited identifier `*` breaks in select list--acts like plain asterisk token
> ------------------------------------------------------------------------------
>
> Key: DRILL-3860
> URL: https://issues.apache.org/jira/browse/DRILL-3860
> Project: Apache Drill
> Issue Type: Bug
> Reporter: Daniel Barclay (Drill)
>
> At least when it appears in a SELECT list, a delimited identifier whose body
> consists of a single asterisk ("{{`\*`}}") is not treated consistently with
> other delimited identifiers (that is, specifying a column whose name matches
> the body ("{{\*}}").)
> For example, in the following, notice how in the first two queries, each
> select list delimited identifier selects the one expected column, but in the
> third query, instead of selecting the one expected column, it selected all
> columns (list the regular "{{*}}" in the fourth query):
> {noformat}
> 0: jdbc:drill:zk=local> SELECT `a` FROM (VALUES (1, 2, 3)) AS T(a, `.`, `*`);
> +----+
> | a |
> +----+
> | 1 |
> +----+
> 1 row selected (0.132 seconds)
> 0: jdbc:drill:zk=local> SELECT `.` FROM (VALUES (1, 2, 3)) AS T(a, `.`, `*`);
> +----+
> | . |
> +----+
> | 2 |
> +----+
> 1 row selected (0.152 seconds)
> 0: jdbc:drill:zk=local> SELECT `*` FROM (VALUES (1, 2, 3)) AS T(a, `.`, `*`);
> +----+----+----+
> | a | . | * |
> +----+----+----+
> | 1 | 2 | 3 |
> +----+----+----+
> 1 row selected (0.136 seconds)
> 0: jdbc:drill:zk=local> SELECT * FROM (VALUES (1, 2, 3)) AS T(a, `.`, `*`);
> +----+----+----+
> | a | . | * |
> +----+----+----+
> | 1 | 2 | 3 |
> +----+----+----+
> 1 row selected (0.128 seconds)
> 0: jdbc:drill:zk=local>
> {noformat}
> Although this acts the same as if the SQL parser treated the delimited
> identifier {{`\*`}} as a plain asterisk token, that does not seem to be the
> actual mechanism for this behavior. (The problem seems to be further
> downstream.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
