[jira] [Commented] (CALCITE-3186) IN expressions in UPDATE statements throws Exceptions
[
https://issues.apache.org/jira/browse/CALCITE-3186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895756#comment-16895756
]
Pressenna commented on CALCITE-3186:
[~danny0405], I created a PR with a test case and a fix for the immediate
problem.
> IN expressions in UPDATE statements throws Exceptions
> -
>
> Key: CALCITE-3186
> URL: https://issues.apache.org/jira/browse/CALCITE-3186
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.20.0
>Reporter: Pressenna
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The patch to get correlated sub-queries working in UPDATE statements had this
> side-effect.
>
> {code:java}
> CREATE TABLE t1 (id1 INT, val1 TEXT);
> CREATE TABLE t2 (id2 INT, val2 TEXT);
> UPDATE t1 SET val1 = 't2' WHERE id1 IN (1, 2, 3);
> -- or
> UPDATE t1 SET val1 = 't2' WHERE id1 IN (SELECT id2 FROM t2);{code}
>
> These seem to raise exceptions now.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (CALCITE-3186) IN expressions in UPDATE statements throws Exceptions
[
https://issues.apache.org/jira/browse/CALCITE-3186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3186:
Labels: pull-request-available (was: )
> IN expressions in UPDATE statements throws Exceptions
> -
>
> Key: CALCITE-3186
> URL: https://issues.apache.org/jira/browse/CALCITE-3186
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.20.0
>Reporter: Pressenna
>Priority: Major
> Labels: pull-request-available
>
> The patch to get correlated sub-queries working in UPDATE statements had this
> side-effect.
>
> {code:java}
> CREATE TABLE t1 (id1 INT, val1 TEXT);
> CREATE TABLE t2 (id2 INT, val2 TEXT);
> UPDATE t1 SET val1 = 't2' WHERE id1 IN (1, 2, 3);
> -- or
> UPDATE t1 SET val1 = 't2' WHERE id1 IN (SELECT id2 FROM t2);{code}
>
> These seem to raise exceptions now.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-3211) List of MutableRel may fail to be identified by SubstitutionVisitor during matching
[
https://issues.apache.org/jira/browse/CALCITE-3211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895748#comment-16895748
]
jin xing commented on CALCITE-3211:
---
Thanks a lot [~julianhyde]
"People should not call {{Lists.transform}} if they are going to use the list
more than once and expect the same results" -- This is true.
I updated the PR according to your comment, it's great if you can take a look
when you have time :)
> List of MutableRel may fail to be identified by SubstitutionVisitor during
> matching
> ---
>
> Key: CALCITE-3211
> URL: https://issues.apache.org/jira/browse/CALCITE-3211
> Project: Calcite
> Issue Type: Bug
>Reporter: jin xing
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current implementation of {{MutableRels::toMutables}} is as below:
> {code:java}
> private static List toMutables(List nodes) {
> return Lists.transform(nodes, MutableRels::toMutable);
> }
> {code}
> Thus every time we {{get}} from the result list, a new {{MutableRel}} will be
> created:
> {code:java}
> private static class TransformingRandomAccessList extends
> AbstractList
> implements RandomAccess, Serializable {
> final List fromList;
> final Function function;
> TransformingRandomAccessList(List fromList, Function extends T> function) {
> this.fromList = checkNotNull(fromList);
> this.function = checkNotNull(function);
> }
> @Override
> public T get(int index) {
> return function.apply(fromList.get(index));
> }
> ..
> {code}
> As a result,
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/plan/SubstitutionVisitor.java#L514
>{{SubstitutionVisitor}} will fail to check whether a node has been
> met/matched before
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (CALCITE-3153) Improve testing in TpcdsTest using assertEqual instead of printing results
[ https://issues.apache.org/jira/browse/CALCITE-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Haisheng Yuan resolved CALCITE-3153. Resolution: Fixed Fix Version/s: 1.21.0 Fixed in https://github.com/apache/calcite/commit/0061b2a172de29acd5859abd7eb93e491d4f4f41, thanks for the PR, [~lishuming]! > Improve testing in TpcdsTest using assertEqual instead of printing results > -- > > Key: CALCITE-3153 > URL: https://issues.apache.org/jira/browse/CALCITE-3153 > Project: Calcite > Issue Type: Test >Reporter: ShuMing Li >Priority: Trivial > Labels: pull-request-available > Fix For: 1.21.0 > > Time Spent: 3h 10m > Remaining Estimate: 0h > > It's a little improve to use `assertEqual` instead of just printing result > in TpcdsTest#testQuery27Builder. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (CALCITE-3219) Allow finer control over which expressions get expanded in SqlToRelConverter
[
https://issues.apache.org/jira/browse/CALCITE-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chan updated CALCITE-3219:
Summary: Allow finer control over which expressions get expanded in
SqlToRelConverter (was: allow finer control over which expressions get
expanded in SqlToRelConverter)
> Allow finer control over which expressions get expanded in SqlToRelConverter
>
>
> Key: CALCITE-3219
> URL: https://issues.apache.org/jira/browse/CALCITE-3219
> Project: Calcite
> Issue Type: Improvement
>Reporter: Pressenna
>Priority: Major
>
> Currently one can control if sub-query expansion happens via
> SqlToRelConverter.Config.isExpand(). This flag is global to the query and
> causes expansion of all supported expression types. For some systems it is
> required that one can dynamically narrow the set of expressions that should
> be expanded.
> In order to allow this, I would propose a new setter with a default
> implementation that returns the above flag.
> {code}
> // a BiPredicate in order to pass both the original query and the expression
> in question for expansion
> java.util.function.BiPredicate
> SqlToRelConverter.Config.getExpandPredicate()
> {code}
> If this is OK, I would provide a PR with the relevant changes.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (CALCITE-2843) Babel parser should parse PostgreSQL-style '::' cast operator
[
https://issues.apache.org/jira/browse/CALCITE-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895710#comment-16895710
]
Danny Chan edited comment on CALCITE-2843 at 7/30/19 2:38 AM:
--
You can just make a static inner subclass of the SqlCastFunction for Postgres
and make a static field for this special operator instance, and add a public
interface like:
{code:java}
public void unparseWithSqlDialect(SqlWriter writer, SqlDialect dialect, int
leftParen, int rightParen) {
// do your special unparse logic
}
{code}
Then you can reference this special operator instance in SqlLibraryOperators
and check this operator in PostgresqlSqlDialect.java with
#unparseWithSqlDialect.
was (Author: danny0405):
You can just make a static inner subclass of the SqlCastFunction for Postgres
and make a static field for this special operator instance, and add a public
interface like:
{code:java}
public boolean supportSqlDialect(SqlDialect dialect) {
return true;
}
{code}
Then you can reference this special operator instance in SqlLibraryOperators
and check this operator in PostgresqlSqlDialect.java with #supportSqlDialect.
> Babel parser should parse PostgreSQL-style '::' cast operator
> -
>
> Key: CALCITE-2843
> URL: https://issues.apache.org/jira/browse/CALCITE-2843
> Project: Calcite
> Issue Type: Bug
> Components: babel
>Affects Versions: 1.18.0
>Reporter: Muhammad Gelbana
>Assignee: Muhammad Gelbana
>Priority: Major
> Labels: postgresql, pull-request-available
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> *Code to reproduce the problem*
> {code:java}
> public static void main(String[] args) throws Exception {
> Config parserConfig =
> configBuilder().setConformance(SqlConformanceEnum.BABEL).setParserFactory(SqlBabelParserImpl.FACTORY).build();
> FrameworkConfig frameworkConfig =
> Frameworks.newConfigBuilder().parserConfig(parserConfig).build();
> Planner planner = Frameworks.getPlanner(frameworkConfig);
> String pg = "SELECT 'array_in'::regproc, typtype FROM pg_catalog.pg_type";
> planner.parse(pg);
> }{code}
>
> *Thrown exception*
> {noformat}
> Exception in thread "main" org.apache.calcite.sql.parser.SqlParseException:
> Encountered ":" at line 1, column 18.
> Was expecting one of:
>
> "ORDER" ...
> "LIMIT" ...
> "OFFSET" ...
> "FETCH" ...
> "FROM" ...
> "," ...
> ...
> ...
> ...
> ...
> ...
> ...
> "." ...
> "IN" ...
> "<" ...
> "<=" ...
> ">" ...
> ">=" ...
> "=" ...
> "<>" ...
> "!=" ...
> "+" ...
> "-" ...
> "*" ...
> "/" ...
> "%" ...
> "||" ...
> "[" ...
> "UNION" ...
> "INTERSECT" ...
> "EXCEPT" ...
> "MINUS" ...
>
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.convertException(SqlBabelParserImpl.java:354)
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.normalizeException(SqlBabelParserImpl.java:142)
> at
> org.apache.calcite.sql.parser.SqlParser.parseQuery(SqlParser.java:156)
> at org.apache.calcite.sql.parser.SqlParser.parseStmt(SqlParser.java:181)
> at org.apache.calcite.prepare.PlannerImpl.parse(PlannerImpl.java:174)
> at org.apache.calcite.tools.Planner.parse(Planner.java:50)
> at com.lab.calcite.App2.main(App2.java:23)
> Caused by: org.apache.calcite.sql.parser.babel.ParseException: Encountered
> ":" at line 1, column 18.
> Was expecting one of:
>
> "ORDER" ...
> "LIMIT" ...
> "OFFSET" ...
> "FETCH" ...
> "FROM" ...
> "," ...
> ...
> ...
> ...
> ...
> ...
> ...
> "." ...
> "IN" ...
> "<" ...
> "<=" ...
> ">" ...
> ">=" ...
> "=" ...
> "<>" ...
> "!=" ...
> "+" ...
> "-" ...
> "*" ...
> "/" ...
> "%" ...
> "||" ...
> "[" ...
> "UNION" ...
> "INTERSECT" ...
> "EXCEPT" ...
> "MINUS" ...
>
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.generateParseException(SqlBabelParserImpl.java:31191)
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.jj_consume_token(SqlBabelParserImpl.java:31008)
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.SqlStmtEof(SqlBabelParserImpl.java:877)
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.parseSqlStmtEof(SqlBabelParserImpl.java:198)
> at
> org.apache.calcite.sql.parser.SqlParser.parseQuery(SqlParser.java:148)
> ... 4 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-3081) Literal NULL should be generated in SqlDialect
[
https://issues.apache.org/jira/browse/CALCITE-3081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895711#comment-16895711
]
Feng Zhu commented on CALCITE-3081:
---
Hi, [~julianhyde], we can do something to solve this issue. But under current
strict type validation, it may be not elegant enough. Should we support
implicit type coercion first?
> Literal NULL should be generated in SqlDialect
> --
>
> Key: CALCITE-3081
> URL: https://issues.apache.org/jira/browse/CALCITE-3081
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.19.0
>Reporter: Feng Zhu
>Priority: Minor
>
> In Calcite, this simple query will throw exception during validation, even it
> is ok in many databases.
> {code:java}
> Query:
> final String query = "select NULL as col "
> + "from \"foodmart\".\"product\"";
> Exception
> org.apache.calcite.tools.ValidationException:
> org.apache.calcite.runtime.CalciteContextException: From line 1, column 8 to
> line 1, column 11: Illegal use of 'NULL'
> {code}
> The right way to use 'NULL' in Calcite is:
> {code:java}
> final String query = "select cast(NULL as integer) as col "
> + "from \"foodmart\".\"product\"";
> {code}
> However, the converted query by *RelToSqlConverter* is illegal in Calcite.
> {code:java}
> SELECT NULL AS \"COL\"
> FROM \"foodmart\".\"product\"
> {code}
> The issue is trivial, but it is against to general sense. Maybe we can
> generate NULL literal in SqlDialect?
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-2843) Babel parser should parse PostgreSQL-style '::' cast operator
[
https://issues.apache.org/jira/browse/CALCITE-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895710#comment-16895710
]
Danny Chan commented on CALCITE-2843:
-
You can just make a static inner subclass of the SqlCastFunction for Postgres
and make a static field for this special operator instance, and add a public
interface like:
{code:java}
public boolean supportSqlDialect(SqlDialect dialect) {
return true;
}
{code}
Then you can reference this special operator instance in SqlLibraryOperators
and check this operator in PostgresqlSqlDialect.java with #supportSqlDialect.
> Babel parser should parse PostgreSQL-style '::' cast operator
> -
>
> Key: CALCITE-2843
> URL: https://issues.apache.org/jira/browse/CALCITE-2843
> Project: Calcite
> Issue Type: Bug
> Components: babel
>Affects Versions: 1.18.0
>Reporter: Muhammad Gelbana
>Assignee: Muhammad Gelbana
>Priority: Major
> Labels: postgresql, pull-request-available
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> *Code to reproduce the problem*
> {code:java}
> public static void main(String[] args) throws Exception {
> Config parserConfig =
> configBuilder().setConformance(SqlConformanceEnum.BABEL).setParserFactory(SqlBabelParserImpl.FACTORY).build();
> FrameworkConfig frameworkConfig =
> Frameworks.newConfigBuilder().parserConfig(parserConfig).build();
> Planner planner = Frameworks.getPlanner(frameworkConfig);
> String pg = "SELECT 'array_in'::regproc, typtype FROM pg_catalog.pg_type";
> planner.parse(pg);
> }{code}
>
> *Thrown exception*
> {noformat}
> Exception in thread "main" org.apache.calcite.sql.parser.SqlParseException:
> Encountered ":" at line 1, column 18.
> Was expecting one of:
>
> "ORDER" ...
> "LIMIT" ...
> "OFFSET" ...
> "FETCH" ...
> "FROM" ...
> "," ...
> ...
> ...
> ...
> ...
> ...
> ...
> "." ...
> "IN" ...
> "<" ...
> "<=" ...
> ">" ...
> ">=" ...
> "=" ...
> "<>" ...
> "!=" ...
> "+" ...
> "-" ...
> "*" ...
> "/" ...
> "%" ...
> "||" ...
> "[" ...
> "UNION" ...
> "INTERSECT" ...
> "EXCEPT" ...
> "MINUS" ...
>
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.convertException(SqlBabelParserImpl.java:354)
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.normalizeException(SqlBabelParserImpl.java:142)
> at
> org.apache.calcite.sql.parser.SqlParser.parseQuery(SqlParser.java:156)
> at org.apache.calcite.sql.parser.SqlParser.parseStmt(SqlParser.java:181)
> at org.apache.calcite.prepare.PlannerImpl.parse(PlannerImpl.java:174)
> at org.apache.calcite.tools.Planner.parse(Planner.java:50)
> at com.lab.calcite.App2.main(App2.java:23)
> Caused by: org.apache.calcite.sql.parser.babel.ParseException: Encountered
> ":" at line 1, column 18.
> Was expecting one of:
>
> "ORDER" ...
> "LIMIT" ...
> "OFFSET" ...
> "FETCH" ...
> "FROM" ...
> "," ...
> ...
> ...
> ...
> ...
> ...
> ...
> "." ...
> "IN" ...
> "<" ...
> "<=" ...
> ">" ...
> ">=" ...
> "=" ...
> "<>" ...
> "!=" ...
> "+" ...
> "-" ...
> "*" ...
> "/" ...
> "%" ...
> "||" ...
> "[" ...
> "UNION" ...
> "INTERSECT" ...
> "EXCEPT" ...
> "MINUS" ...
>
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.generateParseException(SqlBabelParserImpl.java:31191)
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.jj_consume_token(SqlBabelParserImpl.java:31008)
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.SqlStmtEof(SqlBabelParserImpl.java:877)
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.parseSqlStmtEof(SqlBabelParserImpl.java:198)
> at
> org.apache.calcite.sql.parser.SqlParser.parseQuery(SqlParser.java:148)
> ... 4 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (CALCITE-3211) List of MutableRel may fail to be identified by SubstitutionVisitor during matching
[
https://issues.apache.org/jira/browse/CALCITE-3211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jin xing updated CALCITE-3211:
--
Summary: List of MutableRel may fail to be identified by
SubstitutionVisitor during matching (was: MutableRel returned from
MutableRels::toMutables may fail to be identified by SubstitutionVisitor
during matching)
> List of MutableRel may fail to be identified by SubstitutionVisitor during
> matching
> ---
>
> Key: CALCITE-3211
> URL: https://issues.apache.org/jira/browse/CALCITE-3211
> Project: Calcite
> Issue Type: Bug
>Reporter: jin xing
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current implementation of {{MutableRels::toMutables}} is as below:
> {code:java}
> private static List toMutables(List nodes) {
> return Lists.transform(nodes, MutableRels::toMutable);
> }
> {code}
> Thus every time we {{get}} from the result list, a new {{MutableRel}} will be
> created:
> {code:java}
> private static class TransformingRandomAccessList extends
> AbstractList
> implements RandomAccess, Serializable {
> final List fromList;
> final Function function;
> TransformingRandomAccessList(List fromList, Function extends T> function) {
> this.fromList = checkNotNull(fromList);
> this.function = checkNotNull(function);
> }
> @Override
> public T get(int index) {
> return function.apply(fromList.get(index));
> }
> ..
> {code}
> As a result,
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/plan/SubstitutionVisitor.java#L514
>{{SubstitutionVisitor}} will fail to check whether a node has been
> met/matched before
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (CALCITE-3211) MutableRel returned from MutableRels::toMutables may fail to be identified by SubstitutionVisitor during matching
[
https://issues.apache.org/jira/browse/CALCITE-3211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jin xing updated CALCITE-3211:
--
Issue Type: Bug (was: Improvement)
> MutableRel returned from MutableRels::toMutables may fail to be identified
> by SubstitutionVisitor during matching
> --
>
> Key: CALCITE-3211
> URL: https://issues.apache.org/jira/browse/CALCITE-3211
> Project: Calcite
> Issue Type: Bug
>Reporter: jin xing
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current implementation of {{MutableRels::toMutables}} is as below:
> {code:java}
> private static List toMutables(List nodes) {
> return Lists.transform(nodes, MutableRels::toMutable);
> }
> {code}
> Thus every time we {{get}} from the result list, a new {{MutableRel}} will be
> created:
> {code:java}
> private static class TransformingRandomAccessList extends
> AbstractList
> implements RandomAccess, Serializable {
> final List fromList;
> final Function function;
> TransformingRandomAccessList(List fromList, Function extends T> function) {
> this.fromList = checkNotNull(fromList);
> this.function = checkNotNull(function);
> }
> @Override
> public T get(int index) {
> return function.apply(fromList.get(index));
> }
> ..
> {code}
> As a result,
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/plan/SubstitutionVisitor.java#L514
>{{SubstitutionVisitor}} will fail to check whether a node has been
> met/matched before
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (CALCITE-3211) MutableRel returned from MutableRels::toMutables may fail to be identified by SubstitutionVisitor during matching
[
https://issues.apache.org/jira/browse/CALCITE-3211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jin xing updated CALCITE-3211:
--
Issue Type: Improvement (was: Bug)
> MutableRel returned from MutableRels::toMutables may fail to be identified
> by SubstitutionVisitor during matching
> --
>
> Key: CALCITE-3211
> URL: https://issues.apache.org/jira/browse/CALCITE-3211
> Project: Calcite
> Issue Type: Improvement
>Reporter: jin xing
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current implementation of {{MutableRels::toMutables}} is as below:
> {code:java}
> private static List toMutables(List nodes) {
> return Lists.transform(nodes, MutableRels::toMutable);
> }
> {code}
> Thus every time we {{get}} from the result list, a new {{MutableRel}} will be
> created:
> {code:java}
> private static class TransformingRandomAccessList extends
> AbstractList
> implements RandomAccess, Serializable {
> final List fromList;
> final Function function;
> TransformingRandomAccessList(List fromList, Function extends T> function) {
> this.fromList = checkNotNull(fromList);
> this.function = checkNotNull(function);
> }
> @Override
> public T get(int index) {
> return function.apply(fromList.get(index));
> }
> ..
> {code}
> As a result,
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/plan/SubstitutionVisitor.java#L514
>{{SubstitutionVisitor}} will fail to check whether a node has been
> met/matched before
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (CALCITE-2496) EXTRACT function: MILLI/MICRO/NANOSECOND parts of a DATE must be zero
[
https://issues.apache.org/jira/browse/CALCITE-2496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chunwei Lei resolved CALCITE-2496.
--
Resolution: Fixed
Fix Version/s: 1.21.0
Fixed in
[https://github.com/apache/calcite/commit/ccad6f982fc0d6bd45424e602ec0432a1bcecda7].
Thank you for your contribution, [~Sergey Nuyanzin]!
> EXTRACT function: MILLI/MICRO/NANOSECOND parts of a DATE must be zero
> -
>
> Key: CALCITE-2496
> URL: https://issues.apache.org/jira/browse/CALCITE-2496
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: Sergey Nuyanzin
>Assignee: Chunwei Lei
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.21.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There was already a similar issue CALCITE-2324 but I'm sorry I did not take
> into account 3 time units. Now I want to cover them here. So all existing
> Timeunits from {{org.apache.calcite.avatica.util.TimeUnit}} which are less
> than a day will be covered
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (CALCITE-3219) allow finer control over which expressions get expanded in SqlToRelConverter
Pressenna created CALCITE-3219:
--
Summary: allow finer control over which expressions get expanded
in SqlToRelConverter
Key: CALCITE-3219
URL: https://issues.apache.org/jira/browse/CALCITE-3219
Project: Calcite
Issue Type: Improvement
Reporter: Pressenna
Currently one can control if sub-query expansion happens via
SqlToRelConverter.Config.isExpand(). This flag is global to the query and
causes expansion of all supported expression types. For some systems it is
required that one can dynamically narrow the set of expressions that should be
expanded.
In order to allow this, I would propose a new setter with a default
implementation that returns the above flag.
{code}
// a BiPredicate in order to pass both the original query and the expression in
question for expansion
java.util.function.BiPredicate
SqlToRelConverter.Config.getExpandPredicate()
{code}
If this is OK, I would provide a PR with the relevant changes.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-3218) Syntax error while parsing DATEADD
[
https://issues.apache.org/jira/browse/CALCITE-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895694#comment-16895694
]
Danny Chan commented on CALCITE-3218:
-
Thanks [~lindseycat] for reporting this, it's better if you can give a test
case which can reproduce this problem in Calcite, it would help the
contributors who has willingness on this issue (more easier to give a fix).
> Syntax error while parsing DATEADD
> --
>
> Key: CALCITE-3218
> URL: https://issues.apache.org/jira/browse/CALCITE-3218
> Project: Calcite
> Issue Type: Bug
>Reporter: Lindsey Meyer
>Assignee: Julian Hyde
>Priority: Major
>
> Syntax error while parsing DATEADD
> {code:java}
> SELECT
> DATE(CONVERT_TIMEZONE('UTC', 'America/Los_Angeles', events.event_date
> )) AS "events.event_date",
> COALESCE(SUM(events.daily_user_count ), 0) AS
> "events.daily_active_users",
> COALESCE(SUM(events.monthly_user_count ), 0) AS
> "events.monthly_active_users"
> FROM public.events_proto AS events
> WHERE
> (((events.event_date ) >= ((CONVERT_TIMEZONE('America/Los_Angeles',
> 'UTC', DATEADD(day,-364, DATE_TRUNC('day',CONVERT_TIMEZONE('UTC',
> 'America/Los_Angeles', GETDATE())) AND (events.event_date ) <
> ((CONVERT_TIMEZONE('America/Los_Angeles', 'UTC', DATEADD(day,365,
> DATEADD(day,-364, DATE_TRUNC('day',CONVERT_TIMEZONE('UTC',
> 'America/Los_Angeles', GETDATE())) ) ))
> GROUP BY 1
> HAVING
> NOT (COALESCE(SUM(events.monthly_user_count ), 0) = 0)
> ORDER BY 1 DESC
> LIMIT 500{code}
>
> {code:java}
> `Column 'year' not found in any table`
> `DATEADD(year,1,...`
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (CALCITE-3218) Syntax error while parsing DATEADD
[
https://issues.apache.org/jira/browse/CALCITE-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde reassigned CALCITE-3218:
Assignee: Julian Hyde
> Syntax error while parsing DATEADD
> --
>
> Key: CALCITE-3218
> URL: https://issues.apache.org/jira/browse/CALCITE-3218
> Project: Calcite
> Issue Type: Bug
>Reporter: Lindsey Meyer
>Assignee: Julian Hyde
>Priority: Major
>
> Syntax error while parsing DATEADD
> {code:java}
> SELECT
> DATE(CONVERT_TIMEZONE('UTC', 'America/Los_Angeles', events.event_date
> )) AS "events.event_date",
> COALESCE(SUM(events.daily_user_count ), 0) AS
> "events.daily_active_users",
> COALESCE(SUM(events.monthly_user_count ), 0) AS
> "events.monthly_active_users"
> FROM public.events_proto AS events
> WHERE
> (((events.event_date ) >= ((CONVERT_TIMEZONE('America/Los_Angeles',
> 'UTC', DATEADD(day,-364, DATE_TRUNC('day',CONVERT_TIMEZONE('UTC',
> 'America/Los_Angeles', GETDATE())) AND (events.event_date ) <
> ((CONVERT_TIMEZONE('America/Los_Angeles', 'UTC', DATEADD(day,365,
> DATEADD(day,-364, DATE_TRUNC('day',CONVERT_TIMEZONE('UTC',
> 'America/Los_Angeles', GETDATE())) ) ))
> GROUP BY 1
> HAVING
> NOT (COALESCE(SUM(events.monthly_user_count ), 0) = 0)
> ORDER BY 1 DESC
> LIMIT 500{code}
>
> {code:java}
> `Column 'year' not found in any table`
> `DATEADD(year,1,...`
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (CALCITE-3218) Syntax error while parsing DATEADD
Lindsey Meyer created CALCITE-3218:
--
Summary: Syntax error while parsing DATEADD
Key: CALCITE-3218
URL: https://issues.apache.org/jira/browse/CALCITE-3218
Project: Calcite
Issue Type: Bug
Reporter: Lindsey Meyer
Syntax error while parsing DATEADD
{code:java}
SELECT
DATE(CONVERT_TIMEZONE('UTC', 'America/Los_Angeles', events.event_date
)) AS "events.event_date",
COALESCE(SUM(events.daily_user_count ), 0) AS
"events.daily_active_users",
COALESCE(SUM(events.monthly_user_count ), 0) AS
"events.monthly_active_users"
FROM public.events_proto AS events
WHERE
(((events.event_date ) >= ((CONVERT_TIMEZONE('America/Los_Angeles',
'UTC', DATEADD(day,-364, DATE_TRUNC('day',CONVERT_TIMEZONE('UTC',
'America/Los_Angeles', GETDATE())) AND (events.event_date ) <
((CONVERT_TIMEZONE('America/Los_Angeles', 'UTC', DATEADD(day,365,
DATEADD(day,-364, DATE_TRUNC('day',CONVERT_TIMEZONE('UTC',
'America/Los_Angeles', GETDATE())) ) ))
GROUP BY 1
HAVING
NOT (COALESCE(SUM(events.monthly_user_count ), 0) = 0)
ORDER BY 1 DESC
LIMIT 500{code}
{code:java}
`Column 'year' not found in any table`
`DATEADD(year,1,...`
{code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (CALCITE-3208) group by ordinal complains about missing column
[
https://issues.apache.org/jira/browse/CALCITE-3208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-3208.
--
Resolution: Not A Problem
> group by ordinal complains about missing column
> ---
>
> Key: CALCITE-3208
> URL: https://issues.apache.org/jira/browse/CALCITE-3208
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.20.0
> Environment:
>
>Reporter: Francis De Brabandere
>Priority: Major
>
> We are trying to use our calcite driver in Tableau
> When Tableau tests the connection it sends this query:
> {code:sql}
> SELECT SUBCOL AS COL FROM ( SELECT 1 AS SUBCOL) SUBQUERY GROUP BY 1{code}
> This fails with
> {{SQLException: Error while executing SQL "SELECT SUBCOL AS COL FROM (
> SELECT 1 AS SUBCOL) SUBQUERY GROUP BY 1": From line 1, column 8 to line 1,
> column 13: Expression 'SUBCOL' is not being grouped}}
>
> Full trace below
> {code:java}
> java.sql.SQLException: Error while executing SQL "SELECT SUBCOL AS COL FROM (
> SELECT 1 AS SUBCOL) SUBQUERY GROUP BY 1": From line 1, column 8 to line 1,
> column 13: Expression 'SUBCOL' is not being grouped
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:522)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.lambda$returns$1(CalciteAssert.java:1440)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.withConnection(CalciteAssert.java:1372)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1438)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1421)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returnsOrdered(CalciteAssert.java:1454)...Caused
> by: org.apache.calcite.runtime.CalciteContextException: From line 1, column
> 8 to line 1, column 13: Expression 'SUBCOL' is not being grouped
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:824)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:809)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4805)
> at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:113)
> at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:40)
> at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:317)
> at
> org.apache.calcite.sql.util.SqlBasicVisitor$ArgHandlerImpl.visitChild(SqlBasicVisitor.java:123)
> at org.apache.calcite.sql.SqlAsOperator.acceptCall(SqlAsOperator.java:121)
> at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:212)
> at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:40)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:139)
> at
> org.apache.calcite.sql.validate.AggregatingSelectScope.checkAggregateExpr(AggregatingSelectScope.java:228)
> at
> org.apache.calcite.sql.validate.AggregatingSelectScope.validateExpr(AggregatingSelectScope.java:237)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateExpr(SqlValidatorImpl.java:4127)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList(SqlValidatorImpl.java:4101)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3376)
> at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:995)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:955)
> at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:216)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:930)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:637)
[jira] [Reopened] (CALCITE-3208) group by ordinal complains about missing column
[
https://issues.apache.org/jira/browse/CALCITE-3208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde reopened CALCITE-3208:
--
> group by ordinal complains about missing column
> ---
>
> Key: CALCITE-3208
> URL: https://issues.apache.org/jira/browse/CALCITE-3208
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.20.0
> Environment:
>
>Reporter: Francis De Brabandere
>Priority: Major
>
> We are trying to use our calcite driver in Tableau
> When Tableau tests the connection it sends this query:
> {code:sql}
> SELECT SUBCOL AS COL FROM ( SELECT 1 AS SUBCOL) SUBQUERY GROUP BY 1{code}
> This fails with
> {{SQLException: Error while executing SQL "SELECT SUBCOL AS COL FROM (
> SELECT 1 AS SUBCOL) SUBQUERY GROUP BY 1": From line 1, column 8 to line 1,
> column 13: Expression 'SUBCOL' is not being grouped}}
>
> Full trace below
> {code:java}
> java.sql.SQLException: Error while executing SQL "SELECT SUBCOL AS COL FROM (
> SELECT 1 AS SUBCOL) SUBQUERY GROUP BY 1": From line 1, column 8 to line 1,
> column 13: Expression 'SUBCOL' is not being grouped
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> at
> org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:522)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.lambda$returns$1(CalciteAssert.java:1440)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.withConnection(CalciteAssert.java:1372)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1438)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1421)
> at
> org.apache.calcite.test.CalciteAssert$AssertQuery.returnsOrdered(CalciteAssert.java:1454)...Caused
> by: org.apache.calcite.runtime.CalciteContextException: From line 1, column
> 8 to line 1, column 13: Expression 'SUBCOL' is not being grouped
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:824)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:809)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4805)
> at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:113)
> at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:40)
> at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:317)
> at
> org.apache.calcite.sql.util.SqlBasicVisitor$ArgHandlerImpl.visitChild(SqlBasicVisitor.java:123)
> at org.apache.calcite.sql.SqlAsOperator.acceptCall(SqlAsOperator.java:121)
> at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:212)
> at org.apache.calcite.sql.validate.AggChecker.visit(AggChecker.java:40)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:139)
> at
> org.apache.calcite.sql.validate.AggregatingSelectScope.checkAggregateExpr(AggregatingSelectScope.java:228)
> at
> org.apache.calcite.sql.validate.AggregatingSelectScope.validateExpr(AggregatingSelectScope.java:237)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateExpr(SqlValidatorImpl.java:4127)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList(SqlValidatorImpl.java:4101)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3376)
> at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:995)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:955)
> at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:216)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:930)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:637)
> at
>
[jira] [Commented] (CALCITE-2302) Implicit type cast support
[
https://issues.apache.org/jira/browse/CALCITE-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895534#comment-16895534
]
Julian Hyde commented on CALCITE-2302:
--
Let's get this reviewed and into 1.21. It's a useful change, and it has been
lingering for too long.
> Implicit type cast support
> --
>
> Key: CALCITE-2302
> URL: https://issues.apache.org/jira/browse/CALCITE-2302
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.17.0
>Reporter: Danny Chan
>Assignee: Danny Chan
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.21.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Now many DBs have support implicit type cast, eg: SqlServer, Oracle, Hive.
> Implicit type cast is an useful function for many cases, So we should support
> this.
> I checkout Calcite code and found that:
> # Now we use a validator to validate our operands types[ through kinds of
> namespaces and scopes ]
> # Most of the validations will finally goes to
> {code:java}
> SqlOperator.validateOperands
> {code}
> # which will use validation logic defined in corresponding
> SqlOperandTypeChecker
> What i'm confused about is where should i put the implicit type cast logic
> in? I figured out 2 ways:
> # Supply a tool class/rules to add casts into a parsed SqlNode tree which
> will then go through the validation logic later on.
> # Unleash the validation logic in kinds of SqlOperandTypeChecker, then
> modify the RelNode/RexNodes tree converted from a validated SqlNode tree to
> add in casts through custom RelOptRules.
> So guys, which of the 2 ways should i go, or if there are better way to do
> this?
> I need your help.
>
> Updated 18-05-30:
> Hi guys, i have made a PR in
> [CALCITE-2302|https://github.com/apache/calcite/pull/706]
> This is design doc: [Calcite Implicit Type Cast
> Design|https://docs.google.com/document/d/1g2RUnLXyp_LjUlO-wbblKuP5hqEu3a_2Mt2k4dh6RwU/edit?usp=sharing].
> This is the conversion types mapping: [Conversion Types
> Mapping|https://docs.google.com/spreadsheets/d/1GhleX5h5W8-kJKh7NMJ4vtoE78pwfaZRJl88ULX_MgU/edit?usp=sharing].
> I really appreciate your suggestions, thx.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (CALCITE-2302) Implicit type cast support
[
https://issues.apache.org/jira/browse/CALCITE-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-2302:
-
Fix Version/s: 1.21.0
> Implicit type cast support
> --
>
> Key: CALCITE-2302
> URL: https://issues.apache.org/jira/browse/CALCITE-2302
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.17.0
>Reporter: Danny Chan
>Assignee: Danny Chan
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.21.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Now many DBs have support implicit type cast, eg: SqlServer, Oracle, Hive.
> Implicit type cast is an useful function for many cases, So we should support
> this.
> I checkout Calcite code and found that:
> # Now we use a validator to validate our operands types[ through kinds of
> namespaces and scopes ]
> # Most of the validations will finally goes to
> {code:java}
> SqlOperator.validateOperands
> {code}
> # which will use validation logic defined in corresponding
> SqlOperandTypeChecker
> What i'm confused about is where should i put the implicit type cast logic
> in? I figured out 2 ways:
> # Supply a tool class/rules to add casts into a parsed SqlNode tree which
> will then go through the validation logic later on.
> # Unleash the validation logic in kinds of SqlOperandTypeChecker, then
> modify the RelNode/RexNodes tree converted from a validated SqlNode tree to
> add in casts through custom RelOptRules.
> So guys, which of the 2 ways should i go, or if there are better way to do
> this?
> I need your help.
>
> Updated 18-05-30:
> Hi guys, i have made a PR in
> [CALCITE-2302|https://github.com/apache/calcite/pull/706]
> This is design doc: [Calcite Implicit Type Cast
> Design|https://docs.google.com/document/d/1g2RUnLXyp_LjUlO-wbblKuP5hqEu3a_2Mt2k4dh6RwU/edit?usp=sharing].
> This is the conversion types mapping: [Conversion Types
> Mapping|https://docs.google.com/spreadsheets/d/1GhleX5h5W8-kJKh7NMJ4vtoE78pwfaZRJl88ULX_MgU/edit?usp=sharing].
> I really appreciate your suggestions, thx.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (CALCITE-3217) Support "SELECT NULL"
[
https://issues.apache.org/jira/browse/CALCITE-3217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-3217:
-
Summary: Support "SELECT NULL" (was: Should Calcite support "select
null"?)
> Support "SELECT NULL"
> -
>
> Key: CALCITE-3217
> URL: https://issues.apache.org/jira/browse/CALCITE-3217
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Xurenhe
>Priority: Minor
> Attachments: Jietu20190728-221651.jpg
>
>
>
> Should Calcite need to support "select null", such as:
> {code:java}
> select null;{code}
> In the version of "1.20.0", it throws exception in
> `org.apache.calcite.sql.validate.SqlValidatorImpl#inferUnknownTypes`.
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-3217) Should Calcite support "select null"?
[
https://issues.apache.org/jira/browse/CALCITE-3217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895526#comment-16895526
]
Julian Hyde commented on CALCITE-3217:
--
Probably a duplicate of CALCITE-3081.
> Should Calcite support "select null"?
> --
>
> Key: CALCITE-3217
> URL: https://issues.apache.org/jira/browse/CALCITE-3217
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Xurenhe
>Priority: Minor
> Attachments: Jietu20190728-221651.jpg
>
>
>
> Should Calcite need to support "select null", such as:
> {code:java}
> select null;{code}
> In the version of "1.20.0", it throws exception in
> `org.apache.calcite.sql.validate.SqlValidatorImpl#inferUnknownTypes`.
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-3081) Literal NULL should be generated in SqlDialect
[
https://issues.apache.org/jira/browse/CALCITE-3081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895519#comment-16895519
]
Julian Hyde commented on CALCITE-3081:
--
[~donnyzone], You've pointed out that what Calcite's SQL parser accepts is
inconsistent with the SQL generated by Calcite's JDBC adapter. But you have not
said what you propose to change to make them consistent.
> Literal NULL should be generated in SqlDialect
> --
>
> Key: CALCITE-3081
> URL: https://issues.apache.org/jira/browse/CALCITE-3081
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.19.0
>Reporter: Feng Zhu
>Priority: Minor
>
> In Calcite, this simple query will throw exception during validation, even it
> is ok in many databases.
> {code:java}
> Query:
> final String query = "select NULL as col "
> + "from \"foodmart\".\"product\"";
> Exception
> org.apache.calcite.tools.ValidationException:
> org.apache.calcite.runtime.CalciteContextException: From line 1, column 8 to
> line 1, column 11: Illegal use of 'NULL'
> {code}
> The right way to use 'NULL' in Calcite is:
> {code:java}
> final String query = "select cast(NULL as integer) as col "
> + "from \"foodmart\".\"product\"";
> {code}
> However, the converted query by *RelToSqlConverter* is illegal in Calcite.
> {code:java}
> SELECT NULL AS \"COL\"
> FROM \"foodmart\".\"product\"
> {code}
> The issue is trivial, but it is against to general sense. Maybe we can
> generate NULL literal in SqlDialect?
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-3211) MutableRel returned from MutableRels::toMutables may fail to be identified by SubstitutionVisitor during matching
[
https://issues.apache.org/jira/browse/CALCITE-3211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895507#comment-16895507
]
Julian Hyde commented on CALCITE-3211:
--
Sounds right. People should not call {{Lists.transform}} if they are going to
use the list more than once and expect the same results.
As an aside, {{toMutables}} is a private method with no javadoc. As such, there
should be no expectations about its behavior by developers. Also, it should not
be referenced in the title of a bug report. Feel free to change or remove the
method if it is not doing what you want.
> MutableRel returned from MutableRels::toMutables may fail to be identified
> by SubstitutionVisitor during matching
> --
>
> Key: CALCITE-3211
> URL: https://issues.apache.org/jira/browse/CALCITE-3211
> Project: Calcite
> Issue Type: Bug
>Reporter: jin xing
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current implementation of {{MutableRels::toMutables}} is as below:
> {code:java}
> private static List toMutables(List nodes) {
> return Lists.transform(nodes, MutableRels::toMutable);
> }
> {code}
> Thus every time we {{get}} from the result list, a new {{MutableRel}} will be
> created:
> {code:java}
> private static class TransformingRandomAccessList extends
> AbstractList
> implements RandomAccess, Serializable {
> final List fromList;
> final Function function;
> TransformingRandomAccessList(List fromList, Function extends T> function) {
> this.fromList = checkNotNull(fromList);
> this.function = checkNotNull(function);
> }
> @Override
> public T get(int index) {
> return function.apply(fromList.get(index));
> }
> ..
> {code}
> As a result,
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/plan/SubstitutionVisitor.java#L514
>{{SubstitutionVisitor}} will fail to check whether a node has been
> met/matched before
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-3213) Support complex type expressions for SqlDataTypeSpec
[
https://issues.apache.org/jira/browse/CALCITE-3213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895502#comment-16895502
]
Julian Hyde commented on CALCITE-3213:
--
I do support the general idea that there should be a SQL representation for
every type, complex or simple, even if we go beyond the SQL standard in doing
this. Good languages have full support for anonymous types (i.e. specifying the
type definition inline, rather than having to define the type beforehand and
reference it by name).
> Support complex type expressions for SqlDataTypeSpec
> -
>
> Key: CALCITE-3213
> URL: https://issues.apache.org/jira/browse/CALCITE-3213
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.20.0
>Reporter: Danny Chan
>Assignee: Danny Chan
>Priority: Major
> Fix For: 1.21.0
>
>
> We should support nested struct type like:
> {code:sql}
> ROW(
> NUMBER(5, 2) NOT NULL AS foo,
> ROW(BOOLEAN AS b, MyUDT NOT NULL AS i) AS rec)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (CALCITE-3210) JDBC adapter should generate "CAST(NULL AS type)" rather than "NULL"
[
https://issues.apache.org/jira/browse/CALCITE-3210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-3210:
-
Summary: JDBC adapter should generate "CAST(NULL AS type)" rather than
"NULL" (was: RelToSqlConverter convert "cast(null as $type)" just as null )
> JDBC adapter should generate "CAST(NULL AS type)" rather than "NULL"
>
>
> Key: CALCITE-3210
> URL: https://issues.apache.org/jira/browse/CALCITE-3210
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
> Environment: mac os
>Reporter: Wang Weidong
>Assignee: Wang Weidong
>Priority: Major
> Labels: pull-request-available
> Fix For: next
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> I have as sql as follows:
> {code:java}
> select cast(null as varchar) as a{code}
> The process step is :
> # parse sql to SqlNode;
> # convert SqlNode to RelNode;
> # convert RelNode to SqlNode;
> # convert SqlNode to string.
> The result string is:
> {code:java}
> "SELECT NULL AS `A`\n"
> + "FROM (VALUES (0)) AS `t` (`ZERO`)"{code}
> Finally, I found that the result string is absent of cast statement for
> "null" which causes the result sql to be invalid.
> Actually, the result I expect is like:
> {code:java}
> "SELECT CAST(NULL AS VARCHAR) AS `A`\n"
> + "FROM (VALUES (0)) AS `t` (`ZERO`)"{code}
>
> Testing code is as follows
> {code:java}
> // code placeholder
> @Test
> public void testSeletNull() throws SqlParseException {
> String sql = "select cast(null as varchar) as a";
> SqlNode sqlNode = parserContext.parseStmt(sql);
> RelNode relNode =
> parserContext.getSqlToRelConverter().convertQuery(sqlNode, true, true).rel;
> SqlNode sqlNodeNew = toSqlNode(relNode);
> Assert.assertEquals(sqlNodeNew.toString(), "SELECT NULL AS `A`\n"
> + "FROM (VALUES (0)) AS `t` (`ZERO`)");
> }
> private static SqlNode toSqlNode(RelNode root) {
> SqlDialect dialect = MysqlSqlDialect.DEFAULT;
> RelToSqlConverter converter = new RelToSqlConverter(dialect == null ?
> dialect : dialect);
> return converter.visitChild(0, root).asStatement();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-3215) Simplification may not fully simplify IsNotNull expressions
[
https://issues.apache.org/jira/browse/CALCITE-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895451#comment-16895451
]
Julian Hyde commented on CALCITE-3215:
--
Is {{SafeRexVisitor.safeOps}} basically the same as the set of strong operators?
In the title, you should say "IS NOT NULL" not "IsNotNull". It will be more
meaningful to users who know SQL but not Calcite internals.
> Simplification may not fully simplify IsNotNull expressions
> ---
>
> Key: CALCITE-3215
> URL: https://issues.apache.org/jira/browse/CALCITE-3215
> Project: Calcite
> Issue Type: Bug
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CALCITE-2929 have added a safety check to avoid simplifying problematic cases.
> The safety check apparently misses some kinds, for example: {{UNARY_PLUS}}
> {code}
> @Test public void testIsNullSimplificationWithUnaryPlus() {
> RexNode expr =
> isNotNull(coalesce(unaryPlus(vInt(1)), vIntNotNull(0)));
> RexNode s = simplify.simplifyUnknownAs(expr, RexUnknownAs.UNKNOWN);
> assertThat(expr.isAlwaysTrue(), is(true));
> assertThat(s, is(trueLiteral));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-3192) Simplify OR incorrectly weaks condition
[
https://issues.apache.org/jira/browse/CALCITE-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895446#comment-16895446
]
Julian Hyde commented on CALCITE-3192:
--
Can you change "weaks" to "weakens" in the JIRA and commit titles. "Weaks" is
not a verb.
Can you document or otherwise clean up {{isSupportedAsOrPredicate}}? How did
you derive the list of which predicates are supported? What is an "or
predicate" anyway?
This double (or triple) negative is difficult to read:
{code}
if (!(Predicate.of(t) == null || !isSupportedAsOrPredicate(t))) {
continue;
}
{code}
> Simplify OR incorrectly weaks condition
> ---
>
> Key: CALCITE-3192
> URL: https://issues.apache.org/jira/browse/CALCITE-3192
> Project: Calcite
> Issue Type: Bug
>Reporter: Jess Balint
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.21.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> RexSimplify is transforming
> * {{OR(AND(>(999, $8), =($2, 'Franklin')), <(100, $8))}}
> * to {{OR(=($2, 'Franklin'), <(100, $8))}}
> the predicates are accumulated in {{simplifyOrTerms()}} but not discarded
> when iterating the second time
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (CALCITE-3192) Simplify OR incorrectly weaks condition
[
https://issues.apache.org/jira/browse/CALCITE-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3192:
Labels: pull-request-available (was: )
> Simplify OR incorrectly weaks condition
> ---
>
> Key: CALCITE-3192
> URL: https://issues.apache.org/jira/browse/CALCITE-3192
> Project: Calcite
> Issue Type: Bug
>Reporter: Jess Balint
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.21.0
>
>
> RexSimplify is transforming
> * {{OR(AND(>(999, $8), =($2, 'Franklin')), <(100, $8))}}
> * to {{OR(=($2, 'Franklin'), <(100, $8))}}
> the predicates are accumulated in {{simplifyOrTerms()}} but not discarded
> when iterating the second time
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (CALCITE-3215) Simplification may not fully simplify IsNotNull expressions
[
https://issues.apache.org/jira/browse/CALCITE-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3215:
Labels: pull-request-available (was: )
> Simplification may not fully simplify IsNotNull expressions
> ---
>
> Key: CALCITE-3215
> URL: https://issues.apache.org/jira/browse/CALCITE-3215
> Project: Calcite
> Issue Type: Bug
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Major
> Labels: pull-request-available
>
> CALCITE-2929 have added a safety check to avoid simplifying problematic cases.
> The safety check apparently misses some kinds, for example: {{UNARY_PLUS}}
> {code}
> @Test public void testIsNullSimplificationWithUnaryPlus() {
> RexNode expr =
> isNotNull(coalesce(unaryPlus(vInt(1)), vIntNotNull(0)));
> RexNode s = simplify.simplifyUnknownAs(expr, RexUnknownAs.UNKNOWN);
> assertThat(expr.isAlwaysTrue(), is(true));
> assertThat(s, is(trueLiteral));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-3202) AssertionError in ElasticsearchAggregate constructor when applying AggregateProjectMergeRule
[
https://issues.apache.org/jira/browse/CALCITE-3202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895261#comment-16895261
]
Kai Guo commented on CALCITE-3202:
--
I just put the same test on Mongo adaptor, it is surprise that the test passed.
Compared the code of ElasticsearchAggregate and MongoAggregate, the difference
is that MongoAggregate constructor doesn't contain code which
ElasticsearchAggregate constructor already had as below
{code:java}
if (getConvention() != input.getConvention()) {
String message = String.format(Locale.ROOT, "%s != %s", getConvention(),
input.getConvention());
throw new AssertionError(message);
}
{code}
And after deleting these code in ElasticsearchAggregate, test passed. It is
obvious that the easiest way to solve this problem is just delete the code, but
since most of the ElasticSearch and Mongo adaptor's rel constructor contains
code like
{code:java}
assert getConvention() == child.getConvention();
{code}
when vm parameter _-ea_ added, the test may still fail.
Thinking as an adaptor, it is okey to make sure that the convention of input
should be the same with itself. As optimizer, it will ensure the rel finally
get the right convention, so it seems that adaptor doesn't need to worry about
the input's convention that much.
Since other adaptors may also have problem like this, I think the 1 way is
better.
> AssertionError in ElasticsearchAggregate constructor when applying
> AggregateProjectMergeRule
>
>
> Key: CALCITE-3202
> URL: https://issues.apache.org/jira/browse/CALCITE-3202
> Project: Calcite
> Issue Type: Bug
> Components: elasticsearch-adapter
>Affects Versions: 1.21.0
>Reporter: Kai Guo
>Priority: Critical
> Attachments: log.log.zip, mapping.json
>
>
> Thanks for viewing this issue! The error occurs when I was trying to execute
> a query with some subquery:
> {code:java}
> select distinct uni_id
> from (
> select uni_id from sample_index where customer_child = 'customer' and
> customer_from_plat = 'FOO'
> and uni_id in (select uni_id from sample_index where customer_child =
> 'trade' and shop_id = '60790435')
> and uni_id in (select uni_id from sample_index where customer_child =
> 'member' and member_id = '884225534')
> )
> {code}
> While running code below:
> {code:java}
> ElasticsearchAggregate(RelOptCluster cluster,
> RelTraitSet traitSet,
> RelNode input,
> ImmutableBitSet groupSet,
> List groupSets,
> List aggCalls) throws InvalidRelException {
> super(cluster, traitSet, input, groupSet, groupSets, aggCalls);
> if (getConvention() != input.getConvention()) {
> String message = String.format(Locale.ROOT, "%s != %s", getConvention(),
> input.getConvention());
> throw new AssertionError(message);
> }{code}
> an AssertionError which means an input of ElasticsearchAggregate has a
> Convention of NONE throws out. stack traces shows as below:
> {code:java}
> java.lang.AssertionError: ELASTICSEARCH != NONE
> at
> org.apache.calcite.adapter.elasticsearch.ElasticsearchAggregate.(ElasticsearchAggregate.java:66)
> at
> org.apache.calcite.adapter.elasticsearch.ElasticsearchAggregate.copy(ElasticsearchAggregate.java:112)
> at
> org.apache.calcite.rel.rules.AggregateProjectMergeRule.apply(AggregateProjectMergeRule.java:113)
> at
> org.apache.calcite.rel.rules.AggregateProjectMergeRule.onMatch(AggregateProjectMergeRule.java:72)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:208)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:631)
> at org.apache.calcite.tools.Programs.lambda$standard$3(Programs.java:283)
> at org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:343)
> at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:189)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:320)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:231)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:637)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:501)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:471)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:231)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement_(CalciteConnectionImpl.java:213)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement(CalciteConnectionImpl.java:202)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement(CalciteConnectionImpl.java:93)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareStatement(AvaticaConnection.java:175)
> at
[jira] [Commented] (CALCITE-2843) Babel parser should parse PostgreSQL-style '::' cast operator
[
https://issues.apache.org/jira/browse/CALCITE-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895252#comment-16895252
]
Muhammad Gelbana commented on CALCITE-2843:
---
But we'll be modifying the original query this way. This won't work for me and
I doubt it will for the majority of Calcite's users. What do you think ?
> Babel parser should parse PostgreSQL-style '::' cast operator
> -
>
> Key: CALCITE-2843
> URL: https://issues.apache.org/jira/browse/CALCITE-2843
> Project: Calcite
> Issue Type: Bug
> Components: babel
>Affects Versions: 1.18.0
>Reporter: Muhammad Gelbana
>Assignee: Muhammad Gelbana
>Priority: Major
> Labels: postgresql, pull-request-available
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> *Code to reproduce the problem*
> {code:java}
> public static void main(String[] args) throws Exception {
> Config parserConfig =
> configBuilder().setConformance(SqlConformanceEnum.BABEL).setParserFactory(SqlBabelParserImpl.FACTORY).build();
> FrameworkConfig frameworkConfig =
> Frameworks.newConfigBuilder().parserConfig(parserConfig).build();
> Planner planner = Frameworks.getPlanner(frameworkConfig);
> String pg = "SELECT 'array_in'::regproc, typtype FROM pg_catalog.pg_type";
> planner.parse(pg);
> }{code}
>
> *Thrown exception*
> {noformat}
> Exception in thread "main" org.apache.calcite.sql.parser.SqlParseException:
> Encountered ":" at line 1, column 18.
> Was expecting one of:
>
> "ORDER" ...
> "LIMIT" ...
> "OFFSET" ...
> "FETCH" ...
> "FROM" ...
> "," ...
> ...
> ...
> ...
> ...
> ...
> ...
> "." ...
> "IN" ...
> "<" ...
> "<=" ...
> ">" ...
> ">=" ...
> "=" ...
> "<>" ...
> "!=" ...
> "+" ...
> "-" ...
> "*" ...
> "/" ...
> "%" ...
> "||" ...
> "[" ...
> "UNION" ...
> "INTERSECT" ...
> "EXCEPT" ...
> "MINUS" ...
>
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.convertException(SqlBabelParserImpl.java:354)
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.normalizeException(SqlBabelParserImpl.java:142)
> at
> org.apache.calcite.sql.parser.SqlParser.parseQuery(SqlParser.java:156)
> at org.apache.calcite.sql.parser.SqlParser.parseStmt(SqlParser.java:181)
> at org.apache.calcite.prepare.PlannerImpl.parse(PlannerImpl.java:174)
> at org.apache.calcite.tools.Planner.parse(Planner.java:50)
> at com.lab.calcite.App2.main(App2.java:23)
> Caused by: org.apache.calcite.sql.parser.babel.ParseException: Encountered
> ":" at line 1, column 18.
> Was expecting one of:
>
> "ORDER" ...
> "LIMIT" ...
> "OFFSET" ...
> "FETCH" ...
> "FROM" ...
> "," ...
> ...
> ...
> ...
> ...
> ...
> ...
> "." ...
> "IN" ...
> "<" ...
> "<=" ...
> ">" ...
> ">=" ...
> "=" ...
> "<>" ...
> "!=" ...
> "+" ...
> "-" ...
> "*" ...
> "/" ...
> "%" ...
> "||" ...
> "[" ...
> "UNION" ...
> "INTERSECT" ...
> "EXCEPT" ...
> "MINUS" ...
>
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.generateParseException(SqlBabelParserImpl.java:31191)
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.jj_consume_token(SqlBabelParserImpl.java:31008)
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.SqlStmtEof(SqlBabelParserImpl.java:877)
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.parseSqlStmtEof(SqlBabelParserImpl.java:198)
> at
> org.apache.calcite.sql.parser.SqlParser.parseQuery(SqlParser.java:148)
> ... 4 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-2843) Babel parser should parse PostgreSQL-style '::' cast operator
[
https://issues.apache.org/jira/browse/CALCITE-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895234#comment-16895234
]
Danny Chan commented on CALCITE-2843:
-
Thanks [~mgelbana], you can just put the :: operator doc in the dialect
specific operators part and the test would pass.
Instead of add a flag isPostgreSQLOperator in the SqlCastFunction, can we just
make remove it, i see this flag is only used in the
[PostgresqlSqlDialect.java|https://github.com/apache/calcite/pull/1066/files#diff-f4c68e688a94bb529fa1be7ff7f81934],
but we already know it is Postgres dialect, so what we need to do is just
check if it is a SqlCastFunction, then you can choose to unparse to normal cast
format or the Postgres dialect format.
[1] [http://calcite.apache.org/docs/reference.html#dialect-specific-operators]
> Babel parser should parse PostgreSQL-style '::' cast operator
> -
>
> Key: CALCITE-2843
> URL: https://issues.apache.org/jira/browse/CALCITE-2843
> Project: Calcite
> Issue Type: Bug
> Components: babel
>Affects Versions: 1.18.0
>Reporter: Muhammad Gelbana
>Assignee: Muhammad Gelbana
>Priority: Major
> Labels: postgresql, pull-request-available
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> *Code to reproduce the problem*
> {code:java}
> public static void main(String[] args) throws Exception {
> Config parserConfig =
> configBuilder().setConformance(SqlConformanceEnum.BABEL).setParserFactory(SqlBabelParserImpl.FACTORY).build();
> FrameworkConfig frameworkConfig =
> Frameworks.newConfigBuilder().parserConfig(parserConfig).build();
> Planner planner = Frameworks.getPlanner(frameworkConfig);
> String pg = "SELECT 'array_in'::regproc, typtype FROM pg_catalog.pg_type";
> planner.parse(pg);
> }{code}
>
> *Thrown exception*
> {noformat}
> Exception in thread "main" org.apache.calcite.sql.parser.SqlParseException:
> Encountered ":" at line 1, column 18.
> Was expecting one of:
>
> "ORDER" ...
> "LIMIT" ...
> "OFFSET" ...
> "FETCH" ...
> "FROM" ...
> "," ...
> ...
> ...
> ...
> ...
> ...
> ...
> "." ...
> "IN" ...
> "<" ...
> "<=" ...
> ">" ...
> ">=" ...
> "=" ...
> "<>" ...
> "!=" ...
> "+" ...
> "-" ...
> "*" ...
> "/" ...
> "%" ...
> "||" ...
> "[" ...
> "UNION" ...
> "INTERSECT" ...
> "EXCEPT" ...
> "MINUS" ...
>
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.convertException(SqlBabelParserImpl.java:354)
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.normalizeException(SqlBabelParserImpl.java:142)
> at
> org.apache.calcite.sql.parser.SqlParser.parseQuery(SqlParser.java:156)
> at org.apache.calcite.sql.parser.SqlParser.parseStmt(SqlParser.java:181)
> at org.apache.calcite.prepare.PlannerImpl.parse(PlannerImpl.java:174)
> at org.apache.calcite.tools.Planner.parse(Planner.java:50)
> at com.lab.calcite.App2.main(App2.java:23)
> Caused by: org.apache.calcite.sql.parser.babel.ParseException: Encountered
> ":" at line 1, column 18.
> Was expecting one of:
>
> "ORDER" ...
> "LIMIT" ...
> "OFFSET" ...
> "FETCH" ...
> "FROM" ...
> "," ...
> ...
> ...
> ...
> ...
> ...
> ...
> "." ...
> "IN" ...
> "<" ...
> "<=" ...
> ">" ...
> ">=" ...
> "=" ...
> "<>" ...
> "!=" ...
> "+" ...
> "-" ...
> "*" ...
> "/" ...
> "%" ...
> "||" ...
> "[" ...
> "UNION" ...
> "INTERSECT" ...
> "EXCEPT" ...
> "MINUS" ...
>
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.generateParseException(SqlBabelParserImpl.java:31191)
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.jj_consume_token(SqlBabelParserImpl.java:31008)
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.SqlStmtEof(SqlBabelParserImpl.java:877)
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.parseSqlStmtEof(SqlBabelParserImpl.java:198)
> at
> org.apache.calcite.sql.parser.SqlParser.parseQuery(SqlParser.java:148)
> ... 4 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (CALCITE-3031) Support for correlated ANY/SOME/ALL sub-query
[
https://issues.apache.org/jira/browse/CALCITE-3031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Haisheng Yuan resolved CALCITE-3031.
Resolution: Fixed
Fix Version/s: 1.21.0
Fixed in
https://github.com/apache/calcite/commit/a1851b67d56f98e14fbe54a96972104585ae8a61.
Thanks for the PR, [~vgarg]!
> Support for correlated ANY/SOME/ALL sub-query
> -
>
> Key: CALCITE-3031
> URL: https://issues.apache.org/jira/browse/CALCITE-3031
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Haisheng Yuan
>Assignee: Vineet Garg
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.21.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Repro:
> {code:java}
> @Test public void testSelectAnyCorrelated() {
> final String sql = "select empno > any(select deptno from dept where
> emp.job = dept.name) from emp\n"
> ;
> checkSubQuery(sql).withLateDecorrelation(true).check();
> }
> {code}
> Error:
> {code:java}
> java.lang.AssertionError: correlation id $cor0 not found in correlation list
> []
> at org.apache.calcite.util.Litmus$1.fail(Litmus.java:31)
> at
> org.apache.calcite.rex.RexChecker.visitCorrelVariable(RexChecker.java:174)
> at
> org.apache.calcite.rex.RexChecker.visitCorrelVariable(RexChecker.java:57)
> at
> org.apache.calcite.rex.RexCorrelVariable.accept(RexCorrelVariable.java:47)
> at
> org.apache.calcite.rex.RexVisitorImpl.visitFieldAccess(RexVisitorImpl.java:98)
> at
> org.apache.calcite.rex.RexChecker.visitFieldAccess(RexChecker.java:149)
> at
> org.apache.calcite.rex.RexChecker.visitFieldAccess(RexChecker.java:57)
> at org.apache.calcite.rex.RexFieldAccess.accept(RexFieldAccess.java:81)
> at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:140)
> at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:57)
> at org.apache.calcite.rex.RexCall.accept(RexCall.java:191)
> at org.apache.calcite.rel.core.Filter.isValid(Filter.java:120)
> at
> org.apache.calcite.test.SqlToRelConverterTest$RelValidityChecker.visit(SqlToRelConverterTest.java:3312)
> at org.apache.calcite.rel.SingleRel.childrenAccept(SingleRel.java:72)
> at org.apache.calcite.rel.RelVisitor.visit(RelVisitor.java:44)
> {code}
> The plan after SubQueryRemoveRule is:
> {code:xml}
> LogicalProject(EXPR$0=[CAST(OR(AND(IS TRUE(>($0, $9)), <>($10, 0)),
> AND(>($10, $11), null, <>($10, 0), IS NOT TRUE(>($0, $9))), AND(>($0, $9),
> <>($10, 0), IS NOT TRUE(>($0, $9)), <=($10, $11:BOOLEAN NOT NULL])
> LogicalJoin(condition=[true], joinType=[inner])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalAggregate(group=[{}], m=[MIN($0)], c=[COUNT()], d=[COUNT($0)])
> LogicalProject(DEPTNO=[$0])
> LogicalFilter(condition=[=($cor0.JOB, $1)])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> {code}
> It should be a Correlate, instead of a Join.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (CALCITE-2843) Babel parser should parse PostgreSQL-style '::' cast operator
[
https://issues.apache.org/jira/browse/CALCITE-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895175#comment-16895175
]
Muhammad Gelbana edited comment on CALCITE-2843 at 7/29/19 11:58 AM:
-
I made the changes you asked for as closely as possible but a single test case
is failing now, that is {{DocumentationTest.testAllFunctionsAreDocumented()}}
because the PostgreSQL casting operator is no exposed as another {{CAST}}
function and it's not documented. It shouldn't be documented of course because
it's syntax isn't unique.
The {{::}} operator is already documented of course. So how do you think I can
bypass the documentation testing for this specific instance of the {{CAST}}
function ?
was (Author: mgelbana):
I made the changes you asked for as closely as possible but a single test case
is failing now, that is \{{DocumentationTest.testAllFunctionsAreDocumented()}}
because the PostgreSQL casting operator is no exposed as another \{{CAST}}
function and it's not documented. It shouldn't be documented of course because
it's syntax isn't unique.
The \{{::}} operator is already documented of course. So how do you think I can
bypass the documentation testing for this specific operator ?
> Babel parser should parse PostgreSQL-style '::' cast operator
> -
>
> Key: CALCITE-2843
> URL: https://issues.apache.org/jira/browse/CALCITE-2843
> Project: Calcite
> Issue Type: Bug
> Components: babel
>Affects Versions: 1.18.0
>Reporter: Muhammad Gelbana
>Assignee: Muhammad Gelbana
>Priority: Major
> Labels: postgresql, pull-request-available
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> *Code to reproduce the problem*
> {code:java}
> public static void main(String[] args) throws Exception {
> Config parserConfig =
> configBuilder().setConformance(SqlConformanceEnum.BABEL).setParserFactory(SqlBabelParserImpl.FACTORY).build();
> FrameworkConfig frameworkConfig =
> Frameworks.newConfigBuilder().parserConfig(parserConfig).build();
> Planner planner = Frameworks.getPlanner(frameworkConfig);
> String pg = "SELECT 'array_in'::regproc, typtype FROM pg_catalog.pg_type";
> planner.parse(pg);
> }{code}
>
> *Thrown exception*
> {noformat}
> Exception in thread "main" org.apache.calcite.sql.parser.SqlParseException:
> Encountered ":" at line 1, column 18.
> Was expecting one of:
>
> "ORDER" ...
> "LIMIT" ...
> "OFFSET" ...
> "FETCH" ...
> "FROM" ...
> "," ...
> ...
> ...
> ...
> ...
> ...
> ...
> "." ...
> "IN" ...
> "<" ...
> "<=" ...
> ">" ...
> ">=" ...
> "=" ...
> "<>" ...
> "!=" ...
> "+" ...
> "-" ...
> "*" ...
> "/" ...
> "%" ...
> "||" ...
> "[" ...
> "UNION" ...
> "INTERSECT" ...
> "EXCEPT" ...
> "MINUS" ...
>
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.convertException(SqlBabelParserImpl.java:354)
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.normalizeException(SqlBabelParserImpl.java:142)
> at
> org.apache.calcite.sql.parser.SqlParser.parseQuery(SqlParser.java:156)
> at org.apache.calcite.sql.parser.SqlParser.parseStmt(SqlParser.java:181)
> at org.apache.calcite.prepare.PlannerImpl.parse(PlannerImpl.java:174)
> at org.apache.calcite.tools.Planner.parse(Planner.java:50)
> at com.lab.calcite.App2.main(App2.java:23)
> Caused by: org.apache.calcite.sql.parser.babel.ParseException: Encountered
> ":" at line 1, column 18.
> Was expecting one of:
>
> "ORDER" ...
> "LIMIT" ...
> "OFFSET" ...
> "FETCH" ...
> "FROM" ...
> "," ...
> ...
> ...
> ...
> ...
> ...
> ...
> "." ...
> "IN" ...
> "<" ...
> "<=" ...
> ">" ...
> ">=" ...
> "=" ...
> "<>" ...
> "!=" ...
> "+" ...
> "-" ...
> "*" ...
> "/" ...
> "%" ...
> "||" ...
> "[" ...
> "UNION" ...
> "INTERSECT" ...
> "EXCEPT" ...
> "MINUS" ...
>
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.generateParseException(SqlBabelParserImpl.java:31191)
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.jj_consume_token(SqlBabelParserImpl.java:31008)
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.SqlStmtEof(SqlBabelParserImpl.java:877)
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.parseSqlStmtEof(SqlBabelParserImpl.java:198)
> at
> org.apache.calcite.sql.parser.SqlParser.parseQuery(SqlParser.java:148)
> ... 4 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-2843) Babel parser should parse PostgreSQL-style '::' cast operator
[
https://issues.apache.org/jira/browse/CALCITE-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895175#comment-16895175
]
Muhammad Gelbana commented on CALCITE-2843:
---
I made the changes you asked for as closely as possible but a single test case
is failing now, that is \{{DocumentationTest.testAllFunctionsAreDocumented()}}
because the PostgreSQL casting operator is no exposed as another \{{CAST}}
function and it's not documented. It shouldn't be documented of course because
it's syntax isn't unique.
The \{{::}} operator is already documented of course. So how do you think I can
bypass the documentation testing for this specific operator ?
> Babel parser should parse PostgreSQL-style '::' cast operator
> -
>
> Key: CALCITE-2843
> URL: https://issues.apache.org/jira/browse/CALCITE-2843
> Project: Calcite
> Issue Type: Bug
> Components: babel
>Affects Versions: 1.18.0
>Reporter: Muhammad Gelbana
>Assignee: Muhammad Gelbana
>Priority: Major
> Labels: postgresql, pull-request-available
> Time Spent: 4h 10m
> Remaining Estimate: 0h
>
> *Code to reproduce the problem*
> {code:java}
> public static void main(String[] args) throws Exception {
> Config parserConfig =
> configBuilder().setConformance(SqlConformanceEnum.BABEL).setParserFactory(SqlBabelParserImpl.FACTORY).build();
> FrameworkConfig frameworkConfig =
> Frameworks.newConfigBuilder().parserConfig(parserConfig).build();
> Planner planner = Frameworks.getPlanner(frameworkConfig);
> String pg = "SELECT 'array_in'::regproc, typtype FROM pg_catalog.pg_type";
> planner.parse(pg);
> }{code}
>
> *Thrown exception*
> {noformat}
> Exception in thread "main" org.apache.calcite.sql.parser.SqlParseException:
> Encountered ":" at line 1, column 18.
> Was expecting one of:
>
> "ORDER" ...
> "LIMIT" ...
> "OFFSET" ...
> "FETCH" ...
> "FROM" ...
> "," ...
> ...
> ...
> ...
> ...
> ...
> ...
> "." ...
> "IN" ...
> "<" ...
> "<=" ...
> ">" ...
> ">=" ...
> "=" ...
> "<>" ...
> "!=" ...
> "+" ...
> "-" ...
> "*" ...
> "/" ...
> "%" ...
> "||" ...
> "[" ...
> "UNION" ...
> "INTERSECT" ...
> "EXCEPT" ...
> "MINUS" ...
>
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.convertException(SqlBabelParserImpl.java:354)
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.normalizeException(SqlBabelParserImpl.java:142)
> at
> org.apache.calcite.sql.parser.SqlParser.parseQuery(SqlParser.java:156)
> at org.apache.calcite.sql.parser.SqlParser.parseStmt(SqlParser.java:181)
> at org.apache.calcite.prepare.PlannerImpl.parse(PlannerImpl.java:174)
> at org.apache.calcite.tools.Planner.parse(Planner.java:50)
> at com.lab.calcite.App2.main(App2.java:23)
> Caused by: org.apache.calcite.sql.parser.babel.ParseException: Encountered
> ":" at line 1, column 18.
> Was expecting one of:
>
> "ORDER" ...
> "LIMIT" ...
> "OFFSET" ...
> "FETCH" ...
> "FROM" ...
> "," ...
> ...
> ...
> ...
> ...
> ...
> ...
> "." ...
> "IN" ...
> "<" ...
> "<=" ...
> ">" ...
> ">=" ...
> "=" ...
> "<>" ...
> "!=" ...
> "+" ...
> "-" ...
> "*" ...
> "/" ...
> "%" ...
> "||" ...
> "[" ...
> "UNION" ...
> "INTERSECT" ...
> "EXCEPT" ...
> "MINUS" ...
>
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.generateParseException(SqlBabelParserImpl.java:31191)
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.jj_consume_token(SqlBabelParserImpl.java:31008)
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.SqlStmtEof(SqlBabelParserImpl.java:877)
> at
> org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.parseSqlStmtEof(SqlBabelParserImpl.java:198)
> at
> org.apache.calcite.sql.parser.SqlParser.parseQuery(SqlParser.java:148)
> ... 4 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-3210) RelToSqlConverter convert "cast(null as $type)" just as null
[
https://issues.apache.org/jira/browse/CALCITE-3210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895018#comment-16895018
]
Danny Chan commented on CALCITE-3210:
-
Seems a bug, thanks for the contribution !
> RelToSqlConverter convert "cast(null as $type)" just as null
> --
>
> Key: CALCITE-3210
> URL: https://issues.apache.org/jira/browse/CALCITE-3210
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
> Environment: mac os
>Reporter: Wang Weidong
>Assignee: Wang Weidong
>Priority: Major
> Labels: pull-request-available
> Fix For: next
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> I have as sql as follows:
> {code:java}
> select cast(null as varchar) as a{code}
> The process step is :
> # parse sql to SqlNode;
> # convert SqlNode to RelNode;
> # convert RelNode to SqlNode;
> # convert SqlNode to string.
> The result string is:
> {code:java}
> "SELECT NULL AS `A`\n"
> + "FROM (VALUES (0)) AS `t` (`ZERO`)"{code}
> Finally, I found that the result string is absent of cast statement for
> "null" which causes the result sql to be invalid.
> Actually, the result I expect is like:
> {code:java}
> "SELECT CAST(NULL AS VARCHAR) AS `A`\n"
> + "FROM (VALUES (0)) AS `t` (`ZERO`)"{code}
>
> Testing code is as follows
> {code:java}
> // code placeholder
> @Test
> public void testSeletNull() throws SqlParseException {
> String sql = "select cast(null as varchar) as a";
> SqlNode sqlNode = parserContext.parseStmt(sql);
> RelNode relNode =
> parserContext.getSqlToRelConverter().convertQuery(sqlNode, true, true).rel;
> SqlNode sqlNodeNew = toSqlNode(relNode);
> Assert.assertEquals(sqlNodeNew.toString(), "SELECT NULL AS `A`\n"
> + "FROM (VALUES (0)) AS `t` (`ZERO`)");
> }
> private static SqlNode toSqlNode(RelNode root) {
> SqlDialect dialect = MysqlSqlDialect.DEFAULT;
> RelToSqlConverter converter = new RelToSqlConverter(dialect == null ?
> dialect : dialect);
> return converter.visitChild(0, root).asStatement();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (CALCITE-3210) RelToSqlConverter convert "cast(null as $type)" just as null
[
https://issues.apache.org/jira/browse/CALCITE-3210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3210:
Labels: pull-request-available (was: )
> RelToSqlConverter convert "cast(null as $type)" just as null
> --
>
> Key: CALCITE-3210
> URL: https://issues.apache.org/jira/browse/CALCITE-3210
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
> Environment: mac os
>Reporter: Wang Weidong
>Assignee: Wang Weidong
>Priority: Major
> Labels: pull-request-available
> Fix For: next
>
>
> I have as sql as follows:
> {code:java}
> select cast(null as varchar) as a{code}
> The process step is :
> # parse sql to SqlNode;
> # convert SqlNode to RelNode;
> # convert RelNode to SqlNode;
> # convert SqlNode to string.
> The result string is:
> {code:java}
> "SELECT NULL AS `A`\n"
> + "FROM (VALUES (0)) AS `t` (`ZERO`)"{code}
> Finally, I found that the result string is absent of cast statement for
> "null" which causes the result sql to be invalid.
> Actually, the result I expect is like:
> {code:java}
> "SELECT CAST(NULL AS VARCHAR) AS `A`\n"
> + "FROM (VALUES (0)) AS `t` (`ZERO`)"{code}
>
> Testing code is as follows
> {code:java}
> // code placeholder
> @Test
> public void testSeletNull() throws SqlParseException {
> String sql = "select cast(null as varchar) as a";
> SqlNode sqlNode = parserContext.parseStmt(sql);
> RelNode relNode =
> parserContext.getSqlToRelConverter().convertQuery(sqlNode, true, true).rel;
> SqlNode sqlNodeNew = toSqlNode(relNode);
> Assert.assertEquals(sqlNodeNew.toString(), "SELECT NULL AS `A`\n"
> + "FROM (VALUES (0)) AS `t` (`ZERO`)");
> }
> private static SqlNode toSqlNode(RelNode root) {
> SqlDialect dialect = MysqlSqlDialect.DEFAULT;
> RelToSqlConverter converter = new RelToSqlConverter(dialect == null ?
> dialect : dialect);
> return converter.visitChild(0, root).asStatement();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
