[
https://issues.apache.org/jira/browse/DRILL-4692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16868858#comment-16868858
]
Paul Rogers commented on DRILL-4692:
------------------------------------
This issue also occurs with Drill's test data. The file
{{jsoninput/twitter_43.json}} contains a number of fields, one of which is a
map of user information called {{user}}. The following query produces the wrong
results:
{code:sql}
select user from cp.`jsoninput/twitter_43.json`
select `user` from cp.`jsoninput/twitter_43.json`
{code}
Both produce a value of {{'Anonymous'}} when run as a test.
The workaround, suggested above, does work:
{code:sql}
select t.`user`, entities from cp.`jsoninput/twitter_43.json`
{code}
The above does produce the full {{user}} map as a result.
Note that, if we use the wildcard, the table's {{user}} column is included, not
the special Drill column:
{code:sql}
select * from cp.`jsoninput/twitter_43.json`
{code}
The above produces the {{user}} map. Indeed, it is from the wildcard form that
I decided to probe {{user}} directly, and was surprised by the results
described above.
I think the current behavior is much more of a bug than a feature. For all
implicit columns, there should be some way to differentiate special columns
from table columns in such a way that column names are the default. Special
name space? (E.g. {{drill.user}}). Function? (E.g. {{user()}}.) How have other
SQL engines resolved this issue?
> Column named user unresolvable
> ------------------------------
>
> Key: DRILL-4692
> URL: https://issues.apache.org/jira/browse/DRILL-4692
> Project: Apache Drill
> Issue Type: Bug
> Components: Server
> Affects Versions: 1.6.0
> Reporter: John Omernik
> Priority: Major
>
> With a set of Parquet files created outside of drill is attempted to be
> processed in Drill, and that set of files contains a column named "user" it
> is impossible to resolve that column, as Drill always replaces user with the
> currently logged in user.
> select user from table -> the logged in user
> select `user` from table -> the logged in user
> There is just no way to address that field. Backticks should allow us to
> access that field.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
