[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&focusedCommentId=16896801#comment-16896801
]
Danny Chan commented on CALCITE-3186:
-
It seems that the original failure is because you use the `TEXT` data type
which does not have any internal implementation in Calcite core, i'm a little
confused why the PR can fix this problem. The PR itself seems a code refactor ~
> 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: 50m
> 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] [Commented] (CALCITE-3215) Simplification may have not fully simplified IS NOT NULL expressions
[
https://issues.apache.org/jira/browse/CALCITE-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16896798#comment-16896798
]
Danny Chan commented on CALCITE-3215:
-
Cast is strong in many RDBMS, for this expression below:
{code:sql}
select cast('abc' as UNSIGNED) from t; -- returns 0 in MYSQL
select cast('abc' as int); -- oracle 11g R2, POSTGRES, MS-SERVER throws invalid
numeric
{code}
but for HIVE and SPARK, it just returns null.
> Simplification may have not fully simplified IS NOT NULL 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] [Resolved] (CALCITE-3207) Fail to convert Join RelNode with like condition to sql statement
[
https://issues.apache.org/jira/browse/CALCITE-3207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chan resolved CALCITE-3207.
-
Resolution: Fixed
Assignee: Danny Chan
Fix Version/s: 1.21.0
Fixed in
[3309396|https://github.com/apache/calcite/commit/3309396dbb73d1f2ec2e32e8ffee0f9e68262db1],
thanks for your PR, [~wojustme] !
> Fail to convert Join RelNode with like condition to sql statement
> -
>
> Key: CALCITE-3207
> URL: https://issues.apache.org/jira/browse/CALCITE-3207
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Xurenhe
>Assignee: Danny Chan
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.21.0
>
> Attachments: image-2019-07-22-23-15-32-107.png
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Hi all
> I have a problem when using calcite, which is 'relnode convert sql statement
> example:
>
> I create a test like below
> {code:java}
> // RelToSqlConverterTest.java
> @Test public void testLeftJoinRel2Sql() {
> final RelBuilder builder = relBuilder();
> final RelNode rel = builder
> .scan("EMP")
> .scan("DEPT")
> .join(JoinRelType.LEFT, builder.and(
> builder.call(SqlStdOperatorTable.EQUALS,
> builder.field(2, 0, "DEPTNO"),
> builder.field(2, 1, "DEPTNO")
> ), builder.call(SqlStdOperatorTable.LIKE,
> builder.field(2, 1, "DNAME"),
> builder.literal("ACCOUNTING"
> .build();
> final String sql = toSql(rel);
> final String expectedSql = "SELECT *\n" +
> "FROM \"scott\".\"EMP\"\n" +
> "LEFT JOIN \"scott\".\"DEPT\" ON \"EMP\".\"DEPTNO\" =
> \"DEPT\".\"DEPTNO\"\n" +
> "AND \"DEPT\".\"DNAME\" LIKE 'ACCOUNTING'";
> assertThat(sql, isLinux(expectedSql));
> }{code}
>
> this relNode cannot convert sql statement.
> I try to debug it,
> `org.apache.calcite.rel.rel2sql.SqlImplementor#convertConditionToSqlNode` may
> forgot to handle this case, which sqlKind is SqlKind.LIKE.
> If it is a bug, I am willing to fix it.
> Thanks.
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-3122) Convert Pig Latin scripts into Calcite logical plan
[ https://issues.apache.org/jira/browse/CALCITE-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16896362#comment-16896362 ] Khai Tran commented on CALCITE-3122: [~julianhyde] Just wonder if you have some time to take a look at my second revision? > Convert Pig Latin scripts into Calcite logical plan > > > Key: CALCITE-3122 > URL: https://issues.apache.org/jira/browse/CALCITE-3122 > Project: Calcite > Issue Type: New Feature > Components: core, piglet >Reporter: Khai Tran >Priority: Major > Labels: pull-request-available > Fix For: 1.21.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > We create an internal Calcite repo at LinkedIn and develop APIs to parse any > Pig Latin scripts into Calcite logical plan. The code was tested in nearly > ~1000 Pig scripts written at LinkedIn. > Changes: > 1. piglet: main conversion code live there, include: > * APIs to convert any Pig scripts into RelNode plans or SQL statements > * Use Pig Grunt parser to parse Pig Latin scripts into Pig logical plan > (DAGs) > * Convert Pig schemas into RelDatatype > * Traverse through Pig expression plan and convert Pig expressions into > RexNodes > * Map some basic Pig UDFs to Calcite SQL operators > * Build Calcite UDFs for any other Pig UDFs, including UDFs written in both > Java and Python > * Traverse (DFS) through Pig logical plans to convert each Pig logical nodes > to RelNodes > * Have an optimizer rule to optimize Pig group/cogroup into Aggregate > operators > 2. core: > * Implement other RelNode in Rel2Sql so that Pig can be translated into SQL > * Other minor changes in a few other classes to make Pig to Calcite works -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (CALCITE-1935) Reference implementation for MATCH_RECOGNIZE
[
https://issues.apache.org/jira/browse/CALCITE-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16896325#comment-16896325
]
Julian Hyde commented on CALCITE-1935:
--
OK, I will look at it today or tomorrow. (Please nag me until I do it. This is
important.)
> Reference implementation for MATCH_RECOGNIZE
>
>
> Key: CALCITE-1935
> URL: https://issues.apache.org/jira/browse/CALCITE-1935
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Labels: match
>
> We now have comprehensive support for parsing and validating MATCH_RECOGNIZE
> queries (see CALCITE-1570 and sub-tasks) but we cannot execute them. I know
> the purpose of this work is to do CEP within Flink, but a reference
> implementation that works on non-streaming data would be valuable.
> I propose that we add a class EnumerableMatch that can generate Java code to
> evaluate MATCH_RECOGNIZE queries on Enumerable data. It does not need to be
> efficient. I don't mind if it (say) buffers all the data in memory and makes
> O(n ^ 3) passes over it. People can make it more efficient over time.
> When we have a reference implementation, people can start playing with this
> feature. And we can start building a corpus of data sets, queries, and their
> expected result. The Flink implementation will be able to test against those
> same queries, and should give the same results, even though Flink will be
> reading streaming data.
> Let's create {{match.iq}} with the following query based on
> https://oracle-base.com/articles/12c/pattern-matching-in-oracle-database-12cr1:
> {code}
> !set outputformat mysql
> !use match
> SELECT *
> FROM sales_history MATCH_RECOGNIZE (
> PARTITION BY product
> ORDER BY tstamp
> MEASURES STRT.tstamp AS start_tstamp,
>LAST(UP.tstamp) AS peak_tstamp,
>LAST(DOWN.tstamp) AS end_tstamp,
>MATCH_NUMBER() AS mno
> ONE ROW PER MATCH
> AFTER MATCH SKIP TO LAST DOWN
> PATTERN (STRT UP+ FLAT* DOWN+)
> DEFINE
>UP AS UP.units_sold > PREV(UP.units_sold),
>FLAT AS FLAT.units_sold = PREV(FLAT.units_sold),
>DOWN AS DOWN.units_sold < PREV(DOWN.units_sold)
>) MR
> ORDER BY MR.product, MR.start_tstamp;
> PRODUCTSTART_TSTAM PEAK_TSTAMP END_TSTAMP MNO
> -- --- --- --- --
> TWINKIES 01-OCT-2014 03-OCT-2014 06-OCT-2014 1
> TWINKIES 06-OCT-2014 08-OCT-2014 09-OCT-2014 2
> TWINKIES 09-OCT-2014 13-OCT-2014 16-OCT-2014 3
> TWINKIES 16-OCT-2014 18-OCT-2014 20-OCT-2014 4
> 4 rows selected.
> !ok
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-2906) Record DOT extension does not distinguish between simple and compound identifiers
[
https://issues.apache.org/jira/browse/CALCITE-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16896250#comment-16896250
]
Rong Rong commented on CALCITE-2906:
absolutely. please feel free.
> Record DOT extension does not distinguish between simple and compound
> identifiers
> -
>
> Key: CALCITE-2906
> URL: https://issues.apache.org/jira/browse/CALCITE-2906
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Rong Rong
>Priority: Major
>
> Currently the DOT extensions only supports Simple Identifiers:
> For example:
> * *{{tbl.foo(0).col.bar}}* is parsed as: *{{((`TBL`.`FOO`(0).`COL`).`BAR`)}}*
> However, this is not the case in regular Expression field, for example:
> * *{{tbl.col.bar}}* is parsed as: *{{`TBL`.`COL`.`BAR`}}*
> Parser should support both compound identifier, and simple identifier chain
> after a record type SqlNode.
> Similarly, parsing should also be consistent for other types of expression,
> for example
> * *{{tbl.arr[0].foo.bar}}* is currently parsed as:
> *{{((`TBL`.`ARR`[0].`FOO`).`BAR`)}}*
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (CALCITE-3207) Fail to convert Join RelNode with like condition to sql statement
[
https://issues.apache.org/jira/browse/CALCITE-3207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xurenhe updated CALCITE-3207:
-
Summary: Fail to convert Join RelNode with like condition to sql statement
(was: Bug of 'JoinRelNode Convert SqlStatement')
> Fail to convert Join RelNode with like condition to sql statement
> -
>
> Key: CALCITE-3207
> URL: https://issues.apache.org/jira/browse/CALCITE-3207
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Xurenhe
>Priority: Minor
> Labels: pull-request-available
> Attachments: image-2019-07-22-23-15-32-107.png
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Hi all
> I have a problem when using calcite, which is 'relnode convert sql statement
> example:
>
> I create a test like below
> {code:java}
> // RelToSqlConverterTest.java
> @Test public void testLeftJoinRel2Sql() {
> final RelBuilder builder = relBuilder();
> final RelNode rel = builder
> .scan("EMP")
> .scan("DEPT")
> .join(JoinRelType.LEFT, builder.and(
> builder.call(SqlStdOperatorTable.EQUALS,
> builder.field(2, 0, "DEPTNO"),
> builder.field(2, 1, "DEPTNO")
> ), builder.call(SqlStdOperatorTable.LIKE,
> builder.field(2, 1, "DNAME"),
> builder.literal("ACCOUNTING"
> .build();
> final String sql = toSql(rel);
> final String expectedSql = "SELECT *\n" +
> "FROM \"scott\".\"EMP\"\n" +
> "LEFT JOIN \"scott\".\"DEPT\" ON \"EMP\".\"DEPTNO\" =
> \"DEPT\".\"DEPTNO\"\n" +
> "AND \"DEPT\".\"DNAME\" LIKE 'ACCOUNTING'";
> assertThat(sql, isLinux(expectedSql));
> }{code}
>
> this relNode cannot convert sql statement.
> I try to debug it,
> `org.apache.calcite.rel.rel2sql.SqlImplementor#convertConditionToSqlNode` may
> forgot to handle this case, which sqlKind is SqlKind.LIKE.
> If it is a bug, I am willing to fix it.
> Thanks.
>
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (CALCITE-1935) Reference implementation for MATCH_RECOGNIZE
[
https://issues.apache.org/jira/browse/CALCITE-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16896198#comment-16896198
]
Julian Feinauer commented on CALCITE-1935:
--
Hey [~julianhyde], I submitted a PR which needs a bit of polishing but I think
I need some help for the final steps. See my mail on the list
(https://lists.apache.org/thread.html/475eec9bc95fc05ddabe3721aa0fffd545f77bf4fc5f7a9ea79c690e@%3Cdev.calcite.apache.org%3E).
The PR can be found here https://github.com/apache/calcite/pull/1343.
I hope that I can manage to get these first steps done with your (or others)
help
Thanks already!
> Reference implementation for MATCH_RECOGNIZE
>
>
> Key: CALCITE-1935
> URL: https://issues.apache.org/jira/browse/CALCITE-1935
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Labels: match
>
> We now have comprehensive support for parsing and validating MATCH_RECOGNIZE
> queries (see CALCITE-1570 and sub-tasks) but we cannot execute them. I know
> the purpose of this work is to do CEP within Flink, but a reference
> implementation that works on non-streaming data would be valuable.
> I propose that we add a class EnumerableMatch that can generate Java code to
> evaluate MATCH_RECOGNIZE queries on Enumerable data. It does not need to be
> efficient. I don't mind if it (say) buffers all the data in memory and makes
> O(n ^ 3) passes over it. People can make it more efficient over time.
> When we have a reference implementation, people can start playing with this
> feature. And we can start building a corpus of data sets, queries, and their
> expected result. The Flink implementation will be able to test against those
> same queries, and should give the same results, even though Flink will be
> reading streaming data.
> Let's create {{match.iq}} with the following query based on
> https://oracle-base.com/articles/12c/pattern-matching-in-oracle-database-12cr1:
> {code}
> !set outputformat mysql
> !use match
> SELECT *
> FROM sales_history MATCH_RECOGNIZE (
> PARTITION BY product
> ORDER BY tstamp
> MEASURES STRT.tstamp AS start_tstamp,
>LAST(UP.tstamp) AS peak_tstamp,
>LAST(DOWN.tstamp) AS end_tstamp,
>MATCH_NUMBER() AS mno
> ONE ROW PER MATCH
> AFTER MATCH SKIP TO LAST DOWN
> PATTERN (STRT UP+ FLAT* DOWN+)
> DEFINE
>UP AS UP.units_sold > PREV(UP.units_sold),
>FLAT AS FLAT.units_sold = PREV(FLAT.units_sold),
>DOWN AS DOWN.units_sold < PREV(DOWN.units_sold)
>) MR
> ORDER BY MR.product, MR.start_tstamp;
> PRODUCTSTART_TSTAM PEAK_TSTAMP END_TSTAMP MNO
> -- --- --- --- --
> TWINKIES 01-OCT-2014 03-OCT-2014 06-OCT-2014 1
> TWINKIES 06-OCT-2014 08-OCT-2014 09-OCT-2014 2
> TWINKIES 09-OCT-2014 13-OCT-2014 16-OCT-2014 3
> TWINKIES 16-OCT-2014 18-OCT-2014 20-OCT-2014 4
> 4 rows selected.
> !ok
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (CALCITE-1935) Reference implementation for MATCH_RECOGNIZE
[
https://issues.apache.org/jira/browse/CALCITE-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Feinauer reassigned CALCITE-1935:
Assignee: Julian Hyde (was: Julian Feinauer)
> Reference implementation for MATCH_RECOGNIZE
>
>
> Key: CALCITE-1935
> URL: https://issues.apache.org/jira/browse/CALCITE-1935
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Labels: match
>
> We now have comprehensive support for parsing and validating MATCH_RECOGNIZE
> queries (see CALCITE-1570 and sub-tasks) but we cannot execute them. I know
> the purpose of this work is to do CEP within Flink, but a reference
> implementation that works on non-streaming data would be valuable.
> I propose that we add a class EnumerableMatch that can generate Java code to
> evaluate MATCH_RECOGNIZE queries on Enumerable data. It does not need to be
> efficient. I don't mind if it (say) buffers all the data in memory and makes
> O(n ^ 3) passes over it. People can make it more efficient over time.
> When we have a reference implementation, people can start playing with this
> feature. And we can start building a corpus of data sets, queries, and their
> expected result. The Flink implementation will be able to test against those
> same queries, and should give the same results, even though Flink will be
> reading streaming data.
> Let's create {{match.iq}} with the following query based on
> https://oracle-base.com/articles/12c/pattern-matching-in-oracle-database-12cr1:
> {code}
> !set outputformat mysql
> !use match
> SELECT *
> FROM sales_history MATCH_RECOGNIZE (
> PARTITION BY product
> ORDER BY tstamp
> MEASURES STRT.tstamp AS start_tstamp,
>LAST(UP.tstamp) AS peak_tstamp,
>LAST(DOWN.tstamp) AS end_tstamp,
>MATCH_NUMBER() AS mno
> ONE ROW PER MATCH
> AFTER MATCH SKIP TO LAST DOWN
> PATTERN (STRT UP+ FLAT* DOWN+)
> DEFINE
>UP AS UP.units_sold > PREV(UP.units_sold),
>FLAT AS FLAT.units_sold = PREV(FLAT.units_sold),
>DOWN AS DOWN.units_sold < PREV(DOWN.units_sold)
>) MR
> ORDER BY MR.product, MR.start_tstamp;
> PRODUCTSTART_TSTAM PEAK_TSTAMP END_TSTAMP MNO
> -- --- --- --- --
> TWINKIES 01-OCT-2014 03-OCT-2014 06-OCT-2014 1
> TWINKIES 06-OCT-2014 08-OCT-2014 09-OCT-2014 2
> TWINKIES 09-OCT-2014 13-OCT-2014 16-OCT-2014 3
> TWINKIES 16-OCT-2014 18-OCT-2014 20-OCT-2014 4
> 4 rows selected.
> !ok
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[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&focusedCommentId=16896156#comment-16896156
]
Danny Chan commented on CALCITE-2302:
-
Thanks, [~julianhyde], i have rebase the code again ~
> 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] [Commented] (CALCITE-2906) Record DOT extension does not distinguish between simple and compound identifiers
[
https://issues.apache.org/jira/browse/CALCITE-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16896100#comment-16896100
]
Xurenhe commented on CALCITE-2906:
--
Hi [~walterddr]
Can I follow this issue?
> Record DOT extension does not distinguish between simple and compound
> identifiers
> -
>
> Key: CALCITE-2906
> URL: https://issues.apache.org/jira/browse/CALCITE-2906
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Rong Rong
>Priority: Major
>
> Currently the DOT extensions only supports Simple Identifiers:
> For example:
> * *{{tbl.foo(0).col.bar}}* is parsed as: *{{((`TBL`.`FOO`(0).`COL`).`BAR`)}}*
> However, this is not the case in regular Expression field, for example:
> * *{{tbl.col.bar}}* is parsed as: *{{`TBL`.`COL`.`BAR`}}*
> Parser should support both compound identifier, and simple identifier chain
> after a record type SqlNode.
> Similarly, parsing should also be consistent for other types of expression,
> for example
> * *{{tbl.arr[0].foo.bar}}* is currently parsed as:
> *{{((`TBL`.`ARR`[0].`FOO`).`BAR`)}}*
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (CALCITE-3192) Simplification may weaken OR conditions containing inequalities
[
https://issues.apache.org/jira/browse/CALCITE-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zoltan Haindrich updated CALCITE-3192:
--
Summary: Simplification may weaken OR conditions containing inequalities
(was: Simplification of OR incorrectly weaks condition)
> Simplification may weaken OR conditions containing inequalities
> ---
>
> 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: 20m
> 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) Simplification of OR incorrectly weaks condition
[
https://issues.apache.org/jira/browse/CALCITE-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zoltan Haindrich updated CALCITE-3192:
--
Summary: Simplification of OR incorrectly weaks condition (was: Simplify
OR incorrectly weaks condition)
> Simplification of 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: 20m
> 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] [Commented] (CALCITE-3215) Simplification may have not fully simplified IS NOT NULL expressions
[
https://issues.apache.org/jira/browse/CALCITE-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16895877#comment-16895877
]
Zoltan Haindrich commented on CALCITE-3215:
---
unfortunately no:
* division is not safe, because of division by zero at runtime; however it is
strong
* for cast; some parsing exception may occur at runtime; however it is strong,
since cast(null as x) doesn't really do anything...
I think both strong; and safe properties should be moved to the "kind" ; to
help decide to do something based on the property of the kind.
> Simplification may have not fully simplified IS NOT NULL 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] [Updated] (CALCITE-3215) Simplification may have not fully simplified IS NOT NULL expressions
[
https://issues.apache.org/jira/browse/CALCITE-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zoltan Haindrich updated CALCITE-3215:
--
Summary: Simplification may have not fully simplified IS NOT NULL
expressions (was: Simplification may not fully simplify IsNotNull expressions)
> Simplification may have not fully simplified IS NOT NULL 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] [Updated] (CALCITE-2906) Record DOT extension does not distinguish between simple and compound identifiers
[
https://issues.apache.org/jira/browse/CALCITE-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis updated CALCITE-2906:
-
Fix Version/s: (was: 1.21.0)
> Record DOT extension does not distinguish between simple and compound
> identifiers
> -
>
> Key: CALCITE-2906
> URL: https://issues.apache.org/jira/browse/CALCITE-2906
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Rong Rong
>Priority: Major
>
> Currently the DOT extensions only supports Simple Identifiers:
> For example:
> * *{{tbl.foo(0).col.bar}}* is parsed as: *{{((`TBL`.`FOO`(0).`COL`).`BAR`)}}*
> However, this is not the case in regular Expression field, for example:
> * *{{tbl.col.bar}}* is parsed as: *{{`TBL`.`COL`.`BAR`}}*
> Parser should support both compound identifier, and simple identifier chain
> after a record type SqlNode.
> Similarly, parsing should also be consistent for other types of expression,
> for example
> * *{{tbl.arr[0].foo.bar}}* is currently parsed as:
> *{{((`TBL`.`ARR`[0].`FOO`).`BAR`)}}*
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
