[
https://issues.apache.org/jira/browse/ASTERIXDB-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15404894#comment-15404894
]
Yingyi Bu edited comment on ASTERIXDB-1560 at 8/2/16 10:32 PM:
---------------------------------------------------------------
That's right. (The "not-so-often" cases are that fields (returned from a
subquery) are generated by certain functions, that the compiler can know
exactly the return type, e.g., substr, count, etc.)
In addition to that, what I added recently is the concept of *bounded* "all
possible field name sets" into open types.
There are two cases for *open* types:
CASE 1: for open types associated with a dataset, any field name is possible
for the open part of a dataset record;
CASE 2: however, for open types generated by a SQL-style SELECT (sub-) query,
the compiler can have the knowledge of what "all possible field names" are.
An example of CASE 2 is:
SELECT user_name name
FROM (
SELECT user.alias user_alias, user.name user_name
FROM FacebookUsers user
WHERE user.id = 1
) foo;
The return type of the subquery is "Open:{}", because FacebookUsers.alias is
of type ANY and FacebookUsers.name is of type ANY.
However, the compiler knows that the *bounded* possible field name set is
{"user_alias", "user_name"} for the return type of the subquery, and hence it
is still be able to accurately de-sugar the example query or error it out:-)
In terms of de-sugaring field access with implicit variable references, open
types of CASE 2 offers the similar amount of information as closed types.
was (Author: buyingyi):
That's right. (The rare, abnormal cases are that fields are generated by
certain functions, that the compiler can know exactly the return type, e.g.,
substr, count, etc.)
In addition to that, what I added recently is the concept of *bounded* "all
possible field name sets" into open types.
There are two cases for *open* types:
CASE 1: for open types associated with a dataset, any field name is possible
for the open part of a dataset record;
CASE 2: however, for open types generated by a SQL-style SELECT (sub-) query,
the compiler can have the knowledge of what "all possible field names" are.
An example of CASE 2 is:
SELECT user_name name
FROM (
SELECT user.alias user_alias, user.name user_name
FROM FacebookUsers user
WHERE user.id = 1
) foo;
The return type of the subquery is "Open:{}", because FacebookUsers.alias is
of type ANY and FacebookUsers.name is of type ANY.
However, the compiler knows that the *bounded* possible field name set is
{"user_alias", "user_name"} for the return type of the subquery, and hence it
is still be able to accurately de-sugar the example query or error it out:-)
> Misleading SQL++ error message when variables are undefined
> ------------------------------------------------------------
>
> Key: ASTERIXDB-1560
> URL: https://issues.apache.org/jira/browse/ASTERIXDB-1560
> Project: Apache AsterixDB
> Issue Type: Bug
> Components: AsterixDB, Error Reporting
> Reporter: Michael J. Carey
> Assignee: Yingyi Bu
> Priority: Minor
>
> This query:
> SELECT u.name AS uname, m.message AS message
> FROM GleambookUsers u
> UNNEST GleambookMessages m
> WHERE m.authorId = user.id;
> Yields this error message:
> Cannot resolve ambiguous alias (variable) reference for identifier user
> [AlgebricksException]
> The reference is undefined, not ambiguous, in this case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
