[jira] [Comment Edited] (CALCITE-2981) Syntax error with simple nested select query
[ https://issues.apache.org/jira/browse/CALCITE-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16812050#comment-16812050 ] pingle wang edited comment on CALCITE-2981 at 4/8/19 3:31 AM: -- ```sql select * from ( (select * from test1) test3 ) ``` Occurring Exception is not parsed sub-query test3 table reference correctly, I can try this issue, thanks. was (Author: ambition119): I can try this issue, thanks. > Syntax error with simple nested select query > > > Key: CALCITE-2981 > URL: https://issues.apache.org/jira/browse/CALCITE-2981 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.18.0 >Reporter: Vamshi >Priority: Critical > > Below standard sql-92 query reports syntax error in calcite: > create table test1(id integer, name integer); > create table test2(id integer, name integer); > select * from ( > ( select id,name from test1 ) test3 > inner join > ( select id,name from test2) test4 on test4.id = test3.id > ); > Caused by: org.apache.calcite.parser.ParseException: Encountered "test3" at > line 4, column 31. > Was expecting one of: > ")" ... > "ORDER" ... > "LIMIT" ... > "OFFSET" ... > "FETCH" ... > "UNION" ... > "INTERSECT" ... > "EXCEPT" ... > "MINUS" ... > "." ... > "NOT" ... > "IN" ... > "<" ... > "<=" ... > ">" ... > ">=" ... > "=" ... > "<>" ... > "!=" ... > "BETWEEN" ... > "LIKE" ... > "SIMILAR" ... > "+" ... > "-" ... > "*" ... > "/" ... > "%" ... > "||" ... > "AND" ... > "OR" ... > "IS" ... > "MEMBER" ... > "SUBMULTISET" ... > "CONTAINS" ... > "OVERLAPS" ... > "EQUALS" ... > "PRECEDES" ... > "SUCCEEDS" ... > "IMMEDIATELY" ... > "MULTISET" ... > "[" ... > "YEAR" ... > "MONTH" ... > "DAY" ... > "HOUR" ... > "MINUTE" ... > "SECOND" ... > > The above query works in standard databases like postgres/oracle/sql server. > This is a commonly generated query pattern by popular BI tools. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2977) Exception is not thrown out when there are ambiguous field in select list
[
https://issues.apache.org/jira/browse/CALCITE-2977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16812066#comment-16812066
]
pengzhiwei commented on CALCITE-2977:
-
Thank [~julianhyde] for take you time, Please have a review again.
> Exception is not thrown out when there are ambiguous field in select list
> --
>
> Key: CALCITE-2977
> URL: https://issues.apache.org/jira/browse/CALCITE-2977
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.20.0
>Reporter: pengzhiwei
>Assignee: pengzhiwei
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.20.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the following sql:
> {code:java}
> select t0 from (select 1 as t0, 2 as t0 from dept){code}
> _SqlValidatorImpl_ does not throw an exception for the ambiguous field "t0".
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2981) Syntax error with simple nested select query
[ https://issues.apache.org/jira/browse/CALCITE-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16812050#comment-16812050 ] pingle wang commented on CALCITE-2981: -- I can try this issue, thanks. > Syntax error with simple nested select query > > > Key: CALCITE-2981 > URL: https://issues.apache.org/jira/browse/CALCITE-2981 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.18.0 >Reporter: Vamshi >Priority: Critical > > Below standard sql-92 query reports syntax error in calcite: > create table test1(id integer, name integer); > create table test2(id integer, name integer); > select * from ( > ( select id,name from test1 ) test3 > inner join > ( select id,name from test2) test4 on test4.id = test3.id > ); > Caused by: org.apache.calcite.parser.ParseException: Encountered "test3" at > line 4, column 31. > Was expecting one of: > ")" ... > "ORDER" ... > "LIMIT" ... > "OFFSET" ... > "FETCH" ... > "UNION" ... > "INTERSECT" ... > "EXCEPT" ... > "MINUS" ... > "." ... > "NOT" ... > "IN" ... > "<" ... > "<=" ... > ">" ... > ">=" ... > "=" ... > "<>" ... > "!=" ... > "BETWEEN" ... > "LIKE" ... > "SIMILAR" ... > "+" ... > "-" ... > "*" ... > "/" ... > "%" ... > "||" ... > "AND" ... > "OR" ... > "IS" ... > "MEMBER" ... > "SUBMULTISET" ... > "CONTAINS" ... > "OVERLAPS" ... > "EQUALS" ... > "PRECEDES" ... > "SUCCEEDS" ... > "IMMEDIATELY" ... > "MULTISET" ... > "[" ... > "YEAR" ... > "MONTH" ... > "DAY" ... > "HOUR" ... > "MINUTE" ... > "SECOND" ... > > The above query works in standard databases like postgres/oracle/sql server. > This is a commonly generated query pattern by popular BI tools. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2981) Syntax error with simple nested select query
[ https://issues.apache.org/jira/browse/CALCITE-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamshi updated CALCITE-2981: Priority: Critical (was: Major) Description: Below standard sql-92 query reports syntax error in calcite: create table test1(id integer, name integer); create table test2(id integer, name integer); select * from ( ( select id,name from test1 ) test3 inner join ( select id,name from test2) test4 on test4.id = test3.id ); Caused by: org.apache.calcite.parser.ParseException: Encountered "test3" at line 4, column 31. Was expecting one of: ")" ... "ORDER" ... "LIMIT" ... "OFFSET" ... "FETCH" ... "UNION" ... "INTERSECT" ... "EXCEPT" ... "MINUS" ... "." ... "NOT" ... "IN" ... "<" ... "<=" ... ">" ... ">=" ... "=" ... "<>" ... "!=" ... "BETWEEN" ... "LIKE" ... "SIMILAR" ... "+" ... "-" ... "*" ... "/" ... "%" ... "||" ... "AND" ... "OR" ... "IS" ... "MEMBER" ... "SUBMULTISET" ... "CONTAINS" ... "OVERLAPS" ... "EQUALS" ... "PRECEDES" ... "SUCCEEDS" ... "IMMEDIATELY" ... "MULTISET" ... "[" ... "YEAR" ... "MONTH" ... "DAY" ... "HOUR" ... "MINUTE" ... "SECOND" ... The above query works in standard databases like postgres/oracle/sql server. This is a commonly generated query pattern by popular BI tools. was: Below standard sql query reports a syntax error: create table test1(id integer, name integer); create table test2(id integer, name integer); select * from ( ( select id,name from test1 ) test3 inner join ( select id,name from test2) test4 on test4.id = test3.id ); Caused by: org.apache.calcite.parser.ParseException: Encountered "test3" at line 4, column 31. Was expecting one of: ")" ... "ORDER" ... "LIMIT" ... "OFFSET" ... "FETCH" ... "UNION" ... "INTERSECT" ... "EXCEPT" ... "MINUS" ... "." ... "NOT" ... "IN" ... "<" ... "<=" ... ">" ... ">=" ... "=" ... "<>" ... "!=" ... "BETWEEN" ... "LIKE" ... "SIMILAR" ... "+" ... "-" ... "*" ... "/" ... "%" ... "||" ... "AND" ... "OR" ... "IS" ... "MEMBER" ... "SUBMULTISET" ... "CONTAINS" ... "OVERLAPS" ... "EQUALS" ... "PRECEDES" ... "SUCCEEDS" ... "IMMEDIATELY" ... "MULTISET" ... "[" ... "YEAR" ... "MONTH" ... "DAY" ... "HOUR" ... "MINUTE" ... "SECOND" ... The above query works in standard databases like postgres/oracle/sql server > Syntax error with simple nested select query > > > Key: CALCITE-2981 > URL: https://issues.apache.org/jira/browse/CALCITE-2981 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.18.0 >Reporter: Vamshi >Priority: Critical > > Below standard sql-92 query reports syntax error in calcite: > create table test1(id integer, name integer); > create table test2(id integer, name integer); > select * from ( > ( select id,name from test1 ) test3 > inner join > ( select id,name from test2) test4 on test4.id = test3.id > ); > Caused by: org.apache.calcite.parser.ParseException: Encountered "test3" at > line 4, column 31. > Was expecting one of: > ")" ... > "ORDER" ... > "LIMIT" ... > "OFFSET" ... > "FETCH" ... > "UNION" ... > "INTERSECT" ... > "EXCEPT" ... > "MINUS" ... > "." ... > "NOT" ... > "IN" ... > "<" ... > "<=" ... > ">" ... > ">=" ... > "=" ... > "<>" ... > "!=" ... > "BETWEEN" ... > "LIKE" ... > "SIMILAR" ... > "+" ... > "-" ... > "*" ... > "/" ... > "%" ... > "||" ... > "AND" ... > "OR" ... > "IS" ... > "MEMBER" ... > "SUBMULTISET" ... > "CONTAINS" ... > "OVERLAPS" ... > "EQUALS" ... > "PRECEDES" ... > "SUCCEEDS" ... > "IMMEDIATELY" ... > "MULTISET" ... > "[" ... > "YEAR" ... > "MONTH" ... > "DAY" ... > "HOUR" ... > "MINUTE" ... > "SECOND" ... > > The above query works in standard databases like postgres/oracle/sql server. > This is a commonly generated query pattern by popular BI tools. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-299) Divide the join graph into partitions that can be optimized separately
[ https://issues.apache.org/jira/browse/CALCITE-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16811737#comment-16811737 ] Haisheng Yuan commented on CALCITE-299: --- [~julianhyde] Is this still an issue? > Divide the join graph into partitions that can be optimized separately > -- > > Key: CALCITE-299 > URL: https://issues.apache.org/jira/browse/CALCITE-299 > Project: Calcite > Issue Type: Bug >Reporter: GitHub Import >Priority: Major > Labels: github-import > > Currently Optiq's join optimization is exhaustive. The search space increases > combinatorially, so for a query with more than about 8 joins, this is > impractical. I propose a "divide and conquer" approach that tames the search > space but doesn't cut out the important parts of the search space. > First, there is a planning phase that gathers together all joins into a > single mega relational expression, MultiJoinRel. > Then an algorithm builds a join graph, and finds a sub-graph (tree) that > minimizes some cost function. Then divide that sub-graph into clusters; the > nodes in a cluster are tightly connected, and the links between clusters are > relatively loosely connected. > The output of this algorithm is the graph, partitioned into moderately sized > groups of nodes (say 5 - 7 maximum). Typically, in a multi-star query, each > group of nodes would have a "fact table" at its center, surrounded by > "dimension tables" connected by many-to-one relationships. (Fact table and > dimension table are relative terms.) > We put in place fire walls (maybe a special kind of RelNode) to prevent join > transformation rules from working across clusters. Then we invoke the > conventional planning process. > Imported from GitHub > Url: https://github.com/julianhyde/optiq/issues/299 > Created by: [julianhyde|https://github.com/julianhyde] > Labels: > Created at: Wed Jun 11 23:24:08 CEST 2014 > State: open -- This message was sent by Atlassian JIRA (v7.6.3#76005)
