An quoted identifier is still an identifier (Drill uses back tick as quote). Per SQL standard, identifier CURRENT_USER / USER/ CURRENT_SESSION/etc are implicit function calls; no () is required.
I checked Postgre, and seems it has the same behavior. mydb=# create table t1 (id int, "user" varchar(10)); mydb=# insert into t1 values(100, 'ABC'); INSERT 0 1 mydb=# select * from t1; id | user -----+------ 100 | ABC (1 row) mydb=# select user from t1; current_user -------------- postgres (1 row) mydb=# select t1.user from t1; user ------ ABC (1 row) On Mon, May 23, 2016 at 5:12 PM, John Omernik <[email protected]> wrote: > Can (should) things inside back ticks be callable? I guess this makes a > very difficult situation from a usability standpoint because user is a not > uncommon column name (think security logs, web logs, etc) yet in the > current setup there is lots of possibility for assumptions on calling back > tick user back tick and without an error users may have wrong, but "error" > free results. > On May 23, 2016 4:54 PM, "Jinfeng Ni" <[email protected]> wrote: > >> The problem here is that identifier 'user' is not only a reserved >> word, but also represents a special function == current_user() call. >> The identifier 'user', whether it's quoted or not, could mean either >> column name or the function call. Without the table alias, it could >> be ambiguous to sql parser. The table alias informs the parser that >> this identifier is not a function call, but a regular identifier, thus >> removes the ambiguity. >> >> This is different from other cases you use quoted reserved word to >> represent a column name, since those reserved words do not represent a >> special function, thus no ambiguity. >> >> select `update`, `insert` from dfs.tmp.`1.json`; >> +---------+---------+ >> | update | insert | >> +---------+---------+ >> | abc | 100 | >> +---------+---------+ >> >> >> >> On Mon, May 23, 2016 at 10:44 AM, John Omernik <[email protected]> wrote: >> > Ya, as I am testing, this works, however, the users of the system expect >> to >> > be able to use `user` and while I can provide them instructions to use a >> > table alias, I am very worried that they will forget and since it doesn't >> > error, but instead puts in a different string, this could lead to bad >> > downstream results... >> > >> > >> > >> > >> > On Mon, May 23, 2016 at 12:41 PM, John Omernik <[email protected]> wrote: >> > >> >> I filed https://issues.apache.org/jira/browse/DRILL-4692 >> >> >> >> I see an alias would work as a tmp fix, but this should be address (I >> >> wonder if other words may have a problem too?) >> >> >> >> >> >> >> >> On Mon, May 23, 2016 at 12:38 PM, Andries Engelbrecht < >> >> [email protected]> wrote: >> >> >> >>> Hmm interesting. >> >>> >> >>> As a workaround just use a table alias when referencing the column. >> >>> >> >>> >> >>> Might be good to se if there is a JIRA for this, or file one if not. >> >>> >> >>> --Andries >> >>> >> >>> > On May 23, 2016, at 10:28 AM, John Omernik <[email protected]> wrote: >> >>> > >> >>> > I have data with a field name user. >> >>> > >> >>> > When I select, with backticks, it doesn't show the field, but >> instead my >> >>> > current logged in user... >> >>> > >> >>> > >> >>> > select CONVERT_FROM(`user`, 'UTF8') as `user` from table limit 10; >> >>> > >> >>> > >> >>> > Shouldn't the backticks allow me to reference the field properly? >> >>> > >> >>> > John >> >>> >> >>> >> >> >>
