[jira] [Comment Edited] (CALCITE-6074) The size of REAL, DOUBLE, and FLOAT is not consistent
[
https://issues.apache.org/jira/browse/CALCITE-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779713#comment-17779713
]
Mihai Budiu edited comment on CALCITE-6074 at 10/26/23 1:30 AM:
To make matters more confusing, in other SQL dialects FLOAT and REAL are
synonyms, e.g., Databricks.
https://docs.databricks.com/en/sql/language-manual/data-types/float-type.html
In other dialects, e.g., mysql, the size of FLOAT really depends on the
specified precision, so FLOAT can be either of them:
https://dev.mysql.com/doc/refman/8.0/en/floating-point-types.html
was (Author: JIRAUSER295926):
To make matters more confusing, in other SQL dialects FLOAT and REAL are
synonyms, e.g., Databricks.
https://docs.databricks.com/en/sql/language-manual/data-types/float-type.html
In other dialects the size of FLOAT really depends on the specified precision,
so FLOAT can be either of them:
https://docs.databricks.com/en/sql/language-manual/data-types/float-type.html
> The size of REAL, DOUBLE, and FLOAT is not consistent
> -
>
> Key: CALCITE-6074
> URL: https://issues.apache.org/jira/browse/CALCITE-6074
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Mihai Budiu
>Priority: Minor
>
> This stems from the review of CALCITE-6052
> Which one is 8 bytes and which one is 4 bytes?
> The intent seems to be that DOUBLE and FLOAT are synonyms, both using 8
> bytes, (which is very weird for Java users), and REAL is 4 bytes.
> But an audit of the code shows that:
> In AggregateNode.maxMinClass:
> {code:java}
> case FLOAT:
> return max ? MaxFloat.class : MinFloat.class;
> case DOUBLE:
> case REAL:
> return max ? MaxDouble.class : MinDouble.class;
> {code}
> In VisitorDataContext:
> {code:java}
> case DOUBLE:
> return Pair.of(index, rexLiteral.getValueAs(Double.class));
> case REAL:
> return Pair.of(index, rexLiteral.getValueAs(Float.class));
> {code}
> (no case for FLOAT)
> In RelMdSize:
> {code:java}
>case FLOAT:
> case REAL:
>
> return 4d;
> {code}
> in RelDataTypeFactoryImpl:
> {code:java}
> case REAL:
> return createSqlType(SqlTypeName.DECIMAL, 14, 7);
> case FLOAT:
> return createSqlType(SqlTypeName.DECIMAL, 14, 7);
> case DOUBLE:
> // the default max precision is 19, so this is actually DECIMAL(19, 15)
> // but derived system can override the max precision/scale.
> return createSqlType(SqlTypeName.DECIMAL, 30, 15);
> {code}
> The reference.md itself seems to be wrong:
> {code}
> | REAL, FLOAT | 4 byte floating point | 6 decimal digits precision.
> | DOUBLE | 8 byte floating point | 15 decimal digits precision.
> {code}
> and there are many more I haven't even checked!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6074) The size of REAL, DOUBLE, and FLOAT is not consistent
[
https://issues.apache.org/jira/browse/CALCITE-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779713#comment-17779713
]
Mihai Budiu commented on CALCITE-6074:
--
To make matters more confusing, in other SQL dialects FLOAT and REAL are
synonyms, e.g., Databricks.
https://docs.databricks.com/en/sql/language-manual/data-types/float-type.html
In other dialects the size of FLOAT really depends on the specified precision,
so FLOAT can be either of them:
https://docs.databricks.com/en/sql/language-manual/data-types/float-type.html
> The size of REAL, DOUBLE, and FLOAT is not consistent
> -
>
> Key: CALCITE-6074
> URL: https://issues.apache.org/jira/browse/CALCITE-6074
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Mihai Budiu
>Priority: Minor
>
> This stems from the review of CALCITE-6052
> Which one is 8 bytes and which one is 4 bytes?
> The intent seems to be that DOUBLE and FLOAT are synonyms, both using 8
> bytes, (which is very weird for Java users), and REAL is 4 bytes.
> But an audit of the code shows that:
> In AggregateNode.maxMinClass:
> {code:java}
> case FLOAT:
> return max ? MaxFloat.class : MinFloat.class;
> case DOUBLE:
> case REAL:
> return max ? MaxDouble.class : MinDouble.class;
> {code}
> In VisitorDataContext:
> {code:java}
> case DOUBLE:
> return Pair.of(index, rexLiteral.getValueAs(Double.class));
> case REAL:
> return Pair.of(index, rexLiteral.getValueAs(Float.class));
> {code}
> (no case for FLOAT)
> In RelMdSize:
> {code:java}
>case FLOAT:
> case REAL:
>
> return 4d;
> {code}
> in RelDataTypeFactoryImpl:
> {code:java}
> case REAL:
> return createSqlType(SqlTypeName.DECIMAL, 14, 7);
> case FLOAT:
> return createSqlType(SqlTypeName.DECIMAL, 14, 7);
> case DOUBLE:
> // the default max precision is 19, so this is actually DECIMAL(19, 15)
> // but derived system can override the max precision/scale.
> return createSqlType(SqlTypeName.DECIMAL, 30, 15);
> {code}
> The reference.md itself seems to be wrong:
> {code}
> | REAL, FLOAT | 4 byte floating point | 6 decimal digits precision.
> | DOUBLE | 8 byte floating point | 15 decimal digits precision.
> {code}
> and there are many more I haven't even checked!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6074) The size of REAL, DOUBLE, and FLOAT is not consistent
[
https://issues.apache.org/jira/browse/CALCITE-6074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779711#comment-17779711
]
Mihai Budiu commented on CALCITE-6074:
--
There are many more cases in other files which look like this:
{code:java}
case DOUBLE:
case FLOAT: // sic
{code}
so these seem to be consistent with the initial claim that DOUBLE and FLOAT are
synonyms.
> The size of REAL, DOUBLE, and FLOAT is not consistent
> -
>
> Key: CALCITE-6074
> URL: https://issues.apache.org/jira/browse/CALCITE-6074
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Mihai Budiu
>Priority: Minor
>
> This stems from the review of CALCITE-6052
> Which one is 8 bytes and which one is 4 bytes?
> The intent seems to be that DOUBLE and FLOAT are synonyms, both using 8
> bytes, (which is very weird for Java users), and REAL is 4 bytes.
> But an audit of the code shows that:
> In AggregateNode.maxMinClass:
> {code:java}
> case FLOAT:
> return max ? MaxFloat.class : MinFloat.class;
> case DOUBLE:
> case REAL:
> return max ? MaxDouble.class : MinDouble.class;
> {code}
> In VisitorDataContext:
> {code:java}
> case DOUBLE:
> return Pair.of(index, rexLiteral.getValueAs(Double.class));
> case REAL:
> return Pair.of(index, rexLiteral.getValueAs(Float.class));
> {code}
> (no case for FLOAT)
> In RelMdSize:
> {code:java}
>case FLOAT:
> case REAL:
>
> return 4d;
> {code}
> in RelDataTypeFactoryImpl:
> {code:java}
> case REAL:
> return createSqlType(SqlTypeName.DECIMAL, 14, 7);
> case FLOAT:
> return createSqlType(SqlTypeName.DECIMAL, 14, 7);
> case DOUBLE:
> // the default max precision is 19, so this is actually DECIMAL(19, 15)
> // but derived system can override the max precision/scale.
> return createSqlType(SqlTypeName.DECIMAL, 30, 15);
> {code}
> The reference.md itself seems to be wrong:
> {code}
> | REAL, FLOAT | 4 byte floating point | 6 decimal digits precision.
> | DOUBLE | 8 byte floating point | 15 decimal digits precision.
> {code}
> and there are many more I haven't even checked!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6074) The size of REAL, DOUBLE, and FLOAT is not consistent
Mihai Budiu created CALCITE-6074:
Summary: The size of REAL, DOUBLE, and FLOAT is not consistent
Key: CALCITE-6074
URL: https://issues.apache.org/jira/browse/CALCITE-6074
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.35.0
Reporter: Mihai Budiu
This stems from the review of CALCITE-6052
Which one is 8 bytes and which one is 4 bytes?
The intent seems to be that DOUBLE and FLOAT are synonyms, both using 8 bytes,
(which is very weird for Java users), and REAL is 4 bytes.
But an audit of the code shows that:
In AggregateNode.maxMinClass:
{code:java}
case FLOAT:
return max ? MaxFloat.class : MinFloat.class;
case DOUBLE:
case REAL:
return max ? MaxDouble.class : MinDouble.class;
{code}
In VisitorDataContext:
{code:java}
case DOUBLE:
return Pair.of(index, rexLiteral.getValueAs(Double.class));
case REAL:
return Pair.of(index, rexLiteral.getValueAs(Float.class));
{code}
(no case for FLOAT)
In RelMdSize:
{code:java}
case FLOAT:
case REAL:
return 4d;
{code}
in RelDataTypeFactoryImpl:
{code:java}
case REAL:
return createSqlType(SqlTypeName.DECIMAL, 14, 7);
case FLOAT:
return createSqlType(SqlTypeName.DECIMAL, 14, 7);
case DOUBLE:
// the default max precision is 19, so this is actually DECIMAL(19, 15)
// but derived system can override the max precision/scale.
return createSqlType(SqlTypeName.DECIMAL, 30, 15);
{code}
The reference.md itself seems to be wrong:
{code}
| REAL, FLOAT | 4 byte floating point | 6 decimal digits precision.
| DOUBLE | 8 byte floating point | 15 decimal digits precision.
{code}
and there are many more I haven't even checked!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6024) ListSqlOperatorTable is inefficient
[
https://issues.apache.org/jira/browse/CALCITE-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779709#comment-17779709
]
Julian Hyde commented on CALCITE-6024:
--
I've posted a PR; can someone review?
> ListSqlOperatorTable is inefficient
> ---
>
> Key: CALCITE-6024
> URL: https://issues.apache.org/jira/browse/CALCITE-6024
> Project: Calcite
> Issue Type: Improvement
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> {{ListSqlOperatorTable}} is inefficient if it contains a large number of
> operators. It currently examines the operators one by one.
> {{ReflectiveSqlOperatorTable}} (and its subclass, {{SqlStdOperatorTable}})
> builds a map of operators by name (actually two maps, one case-sensitive and
> one case-insensitive).
> {{ListSqlOperatorTable}} should do the same, at least in its immutable form.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6024) ListSqlOperatorTable is inefficient
[
https://issues.apache.org/jira/browse/CALCITE-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-6024:
-
Fix Version/s: 1.36.0
> ListSqlOperatorTable is inefficient
> ---
>
> Key: CALCITE-6024
> URL: https://issues.apache.org/jira/browse/CALCITE-6024
> Project: Calcite
> Issue Type: Improvement
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> {{ListSqlOperatorTable}} is inefficient if it contains a large number of
> operators. It currently examines the operators one by one.
> {{ReflectiveSqlOperatorTable}} (and its subclass, {{SqlStdOperatorTable}})
> builds a map of operators by name (actually two maps, one case-sensitive and
> one case-insensitive).
> {{ListSqlOperatorTable}} should do the same, at least in its immutable form.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6024) ListSqlOperatorTable is inefficient
[
https://issues.apache.org/jira/browse/CALCITE-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6024:
Labels: pull-request-available (was: )
> ListSqlOperatorTable is inefficient
> ---
>
> Key: CALCITE-6024
> URL: https://issues.apache.org/jira/browse/CALCITE-6024
> Project: Calcite
> Issue Type: Improvement
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
> Labels: pull-request-available
>
> {{ListSqlOperatorTable}} is inefficient if it contains a large number of
> operators. It currently examines the operators one by one.
> {{ReflectiveSqlOperatorTable}} (and its subclass, {{SqlStdOperatorTable}})
> builds a map of operators by name (actually two maps, one case-sensitive and
> one case-insensitive).
> {{ListSqlOperatorTable}} should do the same, at least in its immutable form.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-6038) Remove 'ORDER BY ... LIMIT n' when input has at most one row, n >= 1, and there is no 'OFFSET' clause
[
https://issues.apache.org/jira/browse/CALCITE-6038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-6038.
--
Resolution: Fixed
Fixed in
[79f2f61d|https://github.com/apache/calcite/commit/79f2f61dcca9ab57600d3723b147b3e05d25ecb2];
thanks for the PR, [~shenlang]!
> Remove 'ORDER BY ... LIMIT n' when input has at most one row, n >= 1, and
> there is no 'OFFSET' clause
> -
>
> Key: CALCITE-6038
> URL: https://issues.apache.org/jira/browse/CALCITE-6038
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> When a Sort represents 'Order By x Limit n',and its input is guaranteed that
> is at most one row,we could remove this Sort.
> For example, the sql:
> {code:java}
> SELECT count(*) FROM orders ORDER BY 1 LIMIT 10 {code}
> because the {{SELECT count\(*) FROM orders}} row count is 1, it is at most
> one row, then we could remove {{ORDER BY 1 LIMIT 10}}; after the
> optimization, the sql is:
> {code:java}
> SELECT count(*) FROM orders {code}
> Above logic are same as Presto/Trino's
> [RemoveRedundantTopN|https://github.com/prestodb/presto/blob/21ab1ea2425e4bc65532ab156c60333e5a72dd09/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/RemoveRedundantTopN.java#L27C1-L28C34]
> rule:
> This JIRA is enhancement for CALCITE-5994; in 5994, we restrict Sort must be
> pure Order(Offset and Limit is null), but after this jira, this optimization
> could be applied to 'Order By x' Or 'Order By x Limit n'.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6073) Documentation does not specify CAST behavior
Mihai Budiu created CALCITE-6073: Summary: Documentation does not specify CAST behavior Key: CALCITE-6073 URL: https://issues.apache.org/jira/browse/CALCITE-6073 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.35.0 Reporter: Mihai Budiu I could not find documentation on how Calcite implements something like CAST(1.9 AS INT). I suspect that there are multiple implementations, some for compile-time and some for run-time. In the absence of a spec it's not clear that they agree. The SQL standard leaves this behavior at the choice of the implementation. At least RexExecutorImpl uses BigDecimal.intValue for this expression, which means that the result is 1 rather than 2, as I would have guessed. Moreover, there are many tests in SqlOperatorTests which are disabled with "brokenTestsEnabled". Most of these tests look wrong too, claiming that the above cast should fail with an error of out of range, e.g., see testCastWithRoundingToScalar. So reading the test code also does not answer this question. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6038) Remove 'ORDER BY ... LIMIT n' when input has at most one row, n >= 1, and there is no 'OFFSET' clause
[
https://issues.apache.org/jira/browse/CALCITE-6038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-6038:
-
Description:
When a Sort represents 'Order By x Limit n',and its input is guaranteed that is
at most one row,we could remove this Sort.
For example, the sql:
{code:java}
SELECT count(*) FROM orders ORDER BY 1 LIMIT 10 {code}
because the {{SELECT count\(*) FROM orders}} row count is 1, it is at most one
row, then we could remove {{ORDER BY 1 LIMIT 10}}; after the optimization, the
sql is:
{code:java}
SELECT count(*) FROM orders {code}
Above logic are same as Presto/Trino's
[RemoveRedundantTopN|https://github.com/prestodb/presto/blob/21ab1ea2425e4bc65532ab156c60333e5a72dd09/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/RemoveRedundantTopN.java#L27C1-L28C34]
rule:
This JIRA is enhancement for CALCITE-5994; in 5994, we restrict Sort must be
pure Order(Offset and Limit is null), but after this jira, this optimization
could be applied to 'Order By x' Or 'Order By x Limit n'.
was:
When a Sort represents 'Order By x Limit n',and its input is guaranteed that is
at most one row,we could remove this Sort.
For example,the sql:
{code:java}
SELECT count(*) FROM orders ORDER BY 1 LIMIT 10 {code}
because the `SELECT count(*) FROM orders ` row count is 1, it is at most one
row,then we could remove `ORDER BY 1 LIMIT 10 `,after the optimization,the sql
is :
{code:java}
SELECT count(*) FROM orders {code}
Above logic are same as Presto/Trino's
[RemoveRedundantTopN|https://github.com/prestodb/presto/blob/21ab1ea2425e4bc65532ab156c60333e5a72dd09/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/RemoveRedundantTopN.java#L27C1-L28C34]
rule:
This JIRA is enhancement for {-}CALCITE-5994{-}, in -CALCITE-5994- ,we
restrict Sort must be pure Order(Offset and Limit is null),after this jira,this
optimization could be applied to 'Order By x' Or 'Order By x Limit n'.
> Remove 'ORDER BY ... LIMIT n' when input has at most one row, n >= 1, and
> there is no 'OFFSET' clause
> -
>
> Key: CALCITE-6038
> URL: https://issues.apache.org/jira/browse/CALCITE-6038
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: LakeShen
>Assignee: LakeShen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> When a Sort represents 'Order By x Limit n',and its input is guaranteed that
> is at most one row,we could remove this Sort.
> For example, the sql:
> {code:java}
> SELECT count(*) FROM orders ORDER BY 1 LIMIT 10 {code}
> because the {{SELECT count\(*) FROM orders}} row count is 1, it is at most
> one row, then we could remove {{ORDER BY 1 LIMIT 10}}; after the
> optimization, the sql is:
> {code:java}
> SELECT count(*) FROM orders {code}
> Above logic are same as Presto/Trino's
> [RemoveRedundantTopN|https://github.com/prestodb/presto/blob/21ab1ea2425e4bc65532ab156c60333e5a72dd09/presto-main/src/main/java/com/facebook/presto/sql/planner/iterative/rule/RemoveRedundantTopN.java#L27C1-L28C34]
> rule:
> This JIRA is enhancement for CALCITE-5994; in 5994, we restrict Sort must be
> pure Order(Offset and Limit is null), but after this jira, this optimization
> could be applied to 'Order By x' Or 'Order By x Limit n'.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6068) Whitespaces are removed from filter values
[
https://issues.apache.org/jira/browse/CALCITE-6068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779663#comment-17779663
]
Julian Hyde commented on CALCITE-6068:
--
The behavior for CHAR and VARCHAR is, and should be, different because CHAR and
VARCHAR are different.
> Whitespaces are removed from filter values
> --
>
> Key: CALCITE-6068
> URL: https://issues.apache.org/jira/browse/CALCITE-6068
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Petr Masopust
>Priority: Major
>
> SqlImplementor.java has hardcoded "true" for trimming whitespaces in
> Context.toIn method
> ([https://github.com/apache/calcite/blob/c83ac69111fd9e75af5e3615af29a72284667a4a/core/src/main/java/org/apache/calcite/rel/rel2sql/SqlImplementor.java#L908]).
>
> This makes troubles for our customer who use values like "Value 1 " etc.
> (don't ask me why).
> E.g.
> val filter = relBuilder.`in`(
> opportunityId,
> relBuilder.literal("value 1 "),
> relBuilder.literal("value 2 ")
> )
> is translated to "id" IN ('value 1', 'value 2') WITHOUT spaces at the end.
>
> I don't know why is such trimming implemented but calcite should not touch
> user inputs. Please make this at least configurable because I don't know any
> workaround. Obvious one with OR and equalities is optimized to IN and trimmed
> too.
> Test reproducer is in [https://github.com/pmsgd/calcite5888] repo in AppTest
> as testCalcite6068.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CALCITE-6044) Column uniqueness for single-row relations
[
https://issues.apache.org/jira/browse/CALCITE-6044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Jackson reassigned CALCITE-6044:
-
Assignee: Paul Jackson
> Column uniqueness for single-row relations
> --
>
> Key: CALCITE-6044
> URL: https://issues.apache.org/jira/browse/CALCITE-6044
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Paul Jackson
>Assignee: Paul Jackson
>Priority: Major
>
> A single-row relation can result from a {{LIMIT 1}} or an aggregation without
> {{{}GROUP BY{}}}. Every column in one of these relations should be unique by
> virtue of having a max row count of 1.
> When joining with a single-row relation on a key field, the join result
> should no longer require that key field for uniqueness. For example, suppose
> the {{emp}} table had a composite key {{{}(empno,hiredate){}}}. If we join on
> {{hiredate=max(hiredate)}} then {{empno}} alone should be a unique column:
>
> {code:java}
> SELECT * FROM emp A
> JOIN ( SELECT MAX(hiredate) last_hired FROM emp) B
> ON A.hiredate = B.last_hired
> {code}
> {{join(A,B).empno}} should be unique because {{(A.empno,A.hiredate)}} is
> unique and {{A.hiredate}} is effectively constant because it is equal to
> {{{}B.last_hired{}}}.
> Here are some {{RelMetadataTests}} cases that I think should pass.
> {code:java}
> @Test void testColumnUniquenessForLimit1() {
> final String sql = ""
> + "select *\n"
> + "from emp\n"
> + "limit 1";
> sql(sql)
> .assertThatAreColumnsUnique(bitSetOf(0), is(true))
> .assertThatAreColumnsUnique(bitSetOf(1), is(true))
> .assertThatAreColumnsUnique(bitSetOf(), is(true));
> }
> @Test void testColumnUniquenessForJoinOnLimit1() {
> final String sql = ""
> + "select *\n"
> + "from emp A\n"
> + "join (\n"
> + " select * from emp\n"
> + " limit 1) B\n"
> + "on A.empno = B.empno";
> sql(sql)
> .assertThatAreColumnsUnique(bitSetOf(0), is(true))
> .assertThatAreColumnsUnique(bitSetOf(1), is(true))
> .assertThatAreColumnsUnique(bitSetOf(9), is(true))
> .assertThatAreColumnsUnique(bitSetOf(10), is(true))
> .assertThatAreColumnsUnique(bitSetOf(), is(true));
> }
> @Test void testColumnUniquenessForJoinOnAggregation() {
> final String sql = ""
> + "select *\n"
> + "from emp A\n"
> + "join (\n"
> + " select max(empno) AS maxno from emp) B\n"
> + "on A.empno = B.maxno";
> sql(sql)
> .assertThatAreColumnsUnique(bitSetOf(0), is(true))
> .assertThatAreColumnsUnique(bitSetOf(9), is(true))
> .assertThatAreColumnsUnique(bitSetOf(1), is(true))
> .assertThatAreColumnsUnique(bitSetOf(), is(true));
> }
> @Test void testColumnUniquenessForCorrelatedSubquery() {
> final String sql = ""
> + "select *\n"
> + "from emp A\n"
> + "where empno = (\n"
> + " select max(empno) from emp)";
> sql(sql)
> .assertThatAreColumnsUnique(bitSetOf(0), is(true))
> .assertThatAreColumnsUnique(bitSetOf(1), is(true))
> .assertThatAreColumnsUnique(bitSetOf(), is(true));
> } {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5921) SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure
[ https://issues.apache.org/jira/browse/CALCITE-5921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779639#comment-17779639 ] Ruben Q L commented on CALCITE-5921: No problem at all [~mbudiu], happy to help. Adding potential corrections to the PR of the related ticket CALCITE-5990 sounds good, I'll take a look at that one as well. > SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure > --- > > Key: CALCITE-5921 > URL: https://issues.apache.org/jira/browse/CALCITE-5921 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Runkang He >Assignee: Runkang He >Priority: Major > Labels: pull-request-available > Fix For: 1.36.0 > > > SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure. > See more in [code > line|https://github.com/apache/calcite/blob/50c3edfc3d6630528ab51fe836bd50df82cc7db8/testkit/src/main/java/org/apache/calcite/test/SqlOperatorFixtureImpl.java#L160]. > When the parameter `runtime` of SqlOperatorFixture.checkFails is true, it > should execute the query and check runtime failure, but currently it ignores > this, and only checks the parse and validation failure. > When fix this, there are 4 failed test cases in CalciteSqlOperatorTest. > At last, this issue was found when to implement `BIT_GET` function in > CALCITE-5848. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5921) SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure
[ https://issues.apache.org/jira/browse/CALCITE-5921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779615#comment-17779615 ] Mihai Budiu commented on CALCITE-5921: -- I apologize for the complications. One solution in such a case is to just revert the commit and ask me to rebase it on the latest main. Thank you so much for fixing them. In am in the Pacific Time zone, so most of this happened during the night for me. I will review the modified PR which was merged. If there are any corrections needed I will add them in my PR for CALCITE-5990 which is paired with this one. > SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure > --- > > Key: CALCITE-5921 > URL: https://issues.apache.org/jira/browse/CALCITE-5921 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Runkang He >Assignee: Runkang He >Priority: Major > Labels: pull-request-available > Fix For: 1.36.0 > > > SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure. > See more in [code > line|https://github.com/apache/calcite/blob/50c3edfc3d6630528ab51fe836bd50df82cc7db8/testkit/src/main/java/org/apache/calcite/test/SqlOperatorFixtureImpl.java#L160]. > When the parameter `runtime` of SqlOperatorFixture.checkFails is true, it > should execute the query and check runtime failure, but currently it ignores > this, and only checks the parse and validation failure. > When fix this, there are 4 failed test cases in CalciteSqlOperatorTest. > At last, this issue was found when to implement `BIT_GET` function in > CALCITE-5848. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CALCITE-6034) Add `isAutoIncrement` and `isGenerated` arguments to MetaColumn constructor
[
https://issues.apache.org/jira/browse/CALCITE-6034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tanner Clary resolved CALCITE-6034.
---
Resolution: Fixed
Merged via
[519d1ce|https://github.com/apache/calcite-avatica/commit/519d1ceeb04cd99530bceb60c1a8e0966c413541],
thanks for the fix, [~tjbanghart] : )!
> Add `isAutoIncrement` and `isGenerated` arguments to MetaColumn constructor
> ---
>
> Key: CALCITE-6034
> URL: https://issues.apache.org/jira/browse/CALCITE-6034
> Project: Calcite
> Issue Type: Sub-task
> Components: avatica
>Reporter: TJ Banghart
>Assignee: TJ Banghart
>Priority: Minor
> Labels: pull-request-available
> Fix For: avatica-1.24.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Adds {{String isAutoincrement}} and {{String isGenerated}} constructor args
> to {{MetaColum}} class. Previously these were hardcoded as blank strings in
> the constructor.
> This is a blocker for CALCITE-5549 as there is no way to set the
> \{{IS_GENERATED}} value for column metadata.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5921) SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure
[ https://issues.apache.org/jira/browse/CALCITE-5921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779523#comment-17779523 ] Ruben Q L commented on CALCITE-5921: The PR has been merged (thanks [~libenchao] for the reactivity to review it!), CI on master branch is back to stable. > SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure > --- > > Key: CALCITE-5921 > URL: https://issues.apache.org/jira/browse/CALCITE-5921 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Runkang He >Assignee: Runkang He >Priority: Major > Labels: pull-request-available > Fix For: 1.36.0 > > > SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure. > See more in [code > line|https://github.com/apache/calcite/blob/50c3edfc3d6630528ab51fe836bd50df82cc7db8/testkit/src/main/java/org/apache/calcite/test/SqlOperatorFixtureImpl.java#L160]. > When the parameter `runtime` of SqlOperatorFixture.checkFails is true, it > should execute the query and check runtime failure, but currently it ignores > this, and only checks the parse and validation failure. > When fix this, there are 4 failed test cases in CalciteSqlOperatorTest. > At last, this issue was found when to implement `BIT_GET` function in > CALCITE-5848. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6072) OpenTelemetry Trace Context Propagation for Avatica
[ https://issues.apache.org/jira/browse/CALCITE-6072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth updated CALCITE-6072: - Summary: OpenTelemetry Trace Context Propagation for Avatica (was: OpenTelemetry trace context propagation for Avatica) > OpenTelemetry Trace Context Propagation for Avatica > --- > > Key: CALCITE-6072 > URL: https://issues.apache.org/jira/browse/CALCITE-6072 > Project: Calcite > Issue Type: New Feature > Components: avatica >Reporter: Istvan Toth >Priority: Major > > It would be super useful to be able to delegate the trace context via Avatica. > Investigate whether the existing Opentelemetry agent can provide this > functionality transparently, and if not, what do we need to add to Avatica to > enable this. > Can/does opentelemtry-agent add instrumentation to add the context as HTTP > headers in httpclient ? > Can/does opentelemetry-agent add instrumentation to retrieve the context in > Jetty ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6072) OpenTelemetry Trace Context Propagation for Avatica
[ https://issues.apache.org/jira/browse/CALCITE-6072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth updated CALCITE-6072: - Description: It would be super useful to be able to propagate the trace context via Avatica. Investigate whether the existing Opentelemetry agent can provide this functionality transparently, and if not, what do we need to add to Avatica to enable this. Can/does opentelemetry-agent add instrumentation to add the context as HTTP headers in httpclient ? Can/does opentelemetry-agent add instrumentation to retrieve the context in Jetty ? was: It would be super useful to be able to delegate the trace context via Avatica. Investigate whether the existing Opentelemetry agent can provide this functionality transparently, and if not, what do we need to add to Avatica to enable this. Can/does opentelemtry-agent add instrumentation to add the context as HTTP headers in httpclient ? Can/does opentelemetry-agent add instrumentation to retrieve the context in Jetty ? > OpenTelemetry Trace Context Propagation for Avatica > --- > > Key: CALCITE-6072 > URL: https://issues.apache.org/jira/browse/CALCITE-6072 > Project: Calcite > Issue Type: New Feature > Components: avatica >Reporter: Istvan Toth >Priority: Major > > It would be super useful to be able to propagate the trace context via > Avatica. > Investigate whether the existing Opentelemetry agent can provide this > functionality transparently, and if not, what do we need to add to Avatica to > enable this. > Can/does opentelemetry-agent add instrumentation to add the context as HTTP > headers in httpclient ? > Can/does opentelemetry-agent add instrumentation to retrieve the context in > Jetty ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6072) OpenTelemetry trace context propagation for Avatica
Istvan Toth created CALCITE-6072: Summary: OpenTelemetry trace context propagation for Avatica Key: CALCITE-6072 URL: https://issues.apache.org/jira/browse/CALCITE-6072 Project: Calcite Issue Type: New Feature Components: avatica Reporter: Istvan Toth It would be super useful to be able to delegate the trace context via Avatica. Investigate whether the existing Opentelemetry agent can provide this functionality transparently, and if not, what do we need to add to Avatica to enable this. Can/does opentelemtry-agent add instrumentation to add the context as HTTP headers in httpclient ? Can/does opentelemetry-agent add instrumentation to retrieve the context in Jetty ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5921) SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure
[ https://issues.apache.org/jira/browse/CALCITE-5921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779490#comment-17779490 ] Ruben Q L commented on CALCITE-5921: I have created a new PR that aims to fix the broken tests: https://github.com/apache/calcite/pull/3482 > SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure > --- > > Key: CALCITE-5921 > URL: https://issues.apache.org/jira/browse/CALCITE-5921 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Runkang He >Assignee: Runkang He >Priority: Major > Labels: pull-request-available > Fix For: 1.36.0 > > > SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure. > See more in [code > line|https://github.com/apache/calcite/blob/50c3edfc3d6630528ab51fe836bd50df82cc7db8/testkit/src/main/java/org/apache/calcite/test/SqlOperatorFixtureImpl.java#L160]. > When the parameter `runtime` of SqlOperatorFixture.checkFails is true, it > should execute the query and check runtime failure, but currently it ignores > this, and only checks the parse and validation failure. > When fix this, there are 4 failed test cases in CalciteSqlOperatorTest. > At last, this issue was found when to implement `BIT_GET` function in > CALCITE-5848. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-5921) SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure
[ https://issues.apache.org/jira/browse/CALCITE-5921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779451#comment-17779451 ] Ruben Q L edited comment on CALCITE-5921 at 10/25/23 12:10 PM: --- I have the impression that the problem comes from the recent changes introduced by CALCITE-5923 (UPDATE: and CALCITE-6014), which were not part of [~mbudiu]'s PR (because the branch was created before CALCITE-5923/CALCITE-6014 was merged). Probably some adjustments are needed to make the ensemble work fine, wip... was (Author: rubenql): I have the impression that the problem comes from the recent changes introduced by CALCITE-5923, which were not part of [~mbudiu]'s PR (because the branch was created before CALCITE-5923 was merged). Probably some adjustments are needed to make the ensemble work fine, wip... > SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure > --- > > Key: CALCITE-5921 > URL: https://issues.apache.org/jira/browse/CALCITE-5921 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Runkang He >Assignee: Runkang He >Priority: Major > Labels: pull-request-available > Fix For: 1.36.0 > > > SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure. > See more in [code > line|https://github.com/apache/calcite/blob/50c3edfc3d6630528ab51fe836bd50df82cc7db8/testkit/src/main/java/org/apache/calcite/test/SqlOperatorFixtureImpl.java#L160]. > When the parameter `runtime` of SqlOperatorFixture.checkFails is true, it > should execute the query and check runtime failure, but currently it ignores > this, and only checks the parse and validation failure. > When fix this, there are 4 failed test cases in CalciteSqlOperatorTest. > At last, this issue was found when to implement `BIT_GET` function in > CALCITE-5848. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5921) SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure
[ https://issues.apache.org/jira/browse/CALCITE-5921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779473#comment-17779473 ] Benchao Li commented on CALCITE-5921: - AFAIK, the CI runs as a "virtual merge commit" with latest main branch, which means that if there are more commits after the CI runs, that wouldn't be checked in current PR's CI. That says, we only need to check the commits committed after the CI triggered. > SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure > --- > > Key: CALCITE-5921 > URL: https://issues.apache.org/jira/browse/CALCITE-5921 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Runkang He >Assignee: Runkang He >Priority: Major > Labels: pull-request-available > Fix For: 1.36.0 > > > SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure. > See more in [code > line|https://github.com/apache/calcite/blob/50c3edfc3d6630528ab51fe836bd50df82cc7db8/testkit/src/main/java/org/apache/calcite/test/SqlOperatorFixtureImpl.java#L160]. > When the parameter `runtime` of SqlOperatorFixture.checkFails is true, it > should execute the query and check runtime failure, but currently it ignores > this, and only checks the parse and validation failure. > When fix this, there are 4 failed test cases in CalciteSqlOperatorTest. > At last, this issue was found when to implement `BIT_GET` function in > CALCITE-5848. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6070) Incorrect field name after RelFieldTrimmer
[
https://issues.apache.org/jira/browse/CALCITE-6070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779463#comment-17779463
]
LakeShen commented on CALCITE-6070:
---
I think that the alias 'DID' should be keeped after the RelFieldTrimmer.
I test the similar sql in presto,the alias is keeped.So it maybe a bug.
> Incorrect field name after RelFieldTrimmer
> --
>
> Key: CALCITE-6070
> URL: https://issues.apache.org/jira/browse/CALCITE-6070
> Project: Calcite
> Issue Type: Wish
> Components: core
>Affects Versions: 1.35.0
>Reporter: ZheHu
>Priority: Minor
>
> Run the following SQL in SqlToRelConverterTest:
> {code}
> select ename as did from emp where ename='a' limit 10
> {code}
> Got planA without RelFieldTrimmer:
> {code}
> LogicalSort(fetch=[10])
> LogicalProject(DID=[$1])
> LogicalFilter(condition=[=($1, 'a')])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> Got planB with RelFieldTrimmer:
> {code}
> LogicalSort(fetch=[10])
> LogicalFilter(condition=[=($0, 'a')])
> LogicalProject(ENAME=[$1])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> However, the column alia DID for ENAME is missing in planB.
> Maybe we can do something about the trimmer when we have other
> purposes(renaming column is the only purpose for this case).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5921) SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure
[ https://issues.apache.org/jira/browse/CALCITE-5921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779451#comment-17779451 ] Ruben Q L commented on CALCITE-5921: I have the impression that the problem comes from the recent changes introduced by CALCITE-5923, which were not part of [~mbudiu]'s PR (because the branch was created before CALCITE-5923 was merged). Probably some adjustments are needed to make the ensemble work fine, wip... > SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure > --- > > Key: CALCITE-5921 > URL: https://issues.apache.org/jira/browse/CALCITE-5921 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Runkang He >Assignee: Runkang He >Priority: Major > Labels: pull-request-available > Fix For: 1.36.0 > > > SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure. > See more in [code > line|https://github.com/apache/calcite/blob/50c3edfc3d6630528ab51fe836bd50df82cc7db8/testkit/src/main/java/org/apache/calcite/test/SqlOperatorFixtureImpl.java#L160]. > When the parameter `runtime` of SqlOperatorFixture.checkFails is true, it > should execute the query and check runtime failure, but currently it ignores > this, and only checks the parse and validation failure. > When fix this, there are 4 failed test cases in CalciteSqlOperatorTest. > At last, this issue was found when to implement `BIT_GET` function in > CALCITE-5848. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-5921) SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure
[ https://issues.apache.org/jira/browse/CALCITE-5921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779445#comment-17779445 ] Ruben Q L edited comment on CALCITE-5921 at 10/25/23 10:31 AM: --- It seems that, even all the PR checks were green, after the merge some tests (involving CAST) are broken on master https://github.com/apache/calcite/actions/runs/6638635554/ Does anyone have any idea why? Looking into that was (Author: rubenql): It seems that, even all the PR checks were green, after the merge some tests are broken on master https://github.com/apache/calcite/actions/runs/6638635554/ Does anyone have any idea why? Looking into that > SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure > --- > > Key: CALCITE-5921 > URL: https://issues.apache.org/jira/browse/CALCITE-5921 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Runkang He >Assignee: Runkang He >Priority: Major > Labels: pull-request-available > Fix For: 1.36.0 > > > SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure. > See more in [code > line|https://github.com/apache/calcite/blob/50c3edfc3d6630528ab51fe836bd50df82cc7db8/testkit/src/main/java/org/apache/calcite/test/SqlOperatorFixtureImpl.java#L160]. > When the parameter `runtime` of SqlOperatorFixture.checkFails is true, it > should execute the query and check runtime failure, but currently it ignores > this, and only checks the parse and validation failure. > When fix this, there are 4 failed test cases in CalciteSqlOperatorTest. > At last, this issue was found when to implement `BIT_GET` function in > CALCITE-5848. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5921) SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure
[ https://issues.apache.org/jira/browse/CALCITE-5921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779445#comment-17779445 ] Ruben Q L commented on CALCITE-5921: It seems that, even all the PR checks were green, after the merge some tests are broken on master https://github.com/apache/calcite/actions/runs/6638635554/ Does anyone have any idea why? Looking into that > SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure > --- > > Key: CALCITE-5921 > URL: https://issues.apache.org/jira/browse/CALCITE-5921 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Runkang He >Assignee: Runkang He >Priority: Major > Labels: pull-request-available > Fix For: 1.36.0 > > > SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure. > See more in [code > line|https://github.com/apache/calcite/blob/50c3edfc3d6630528ab51fe836bd50df82cc7db8/testkit/src/main/java/org/apache/calcite/test/SqlOperatorFixtureImpl.java#L160]. > When the parameter `runtime` of SqlOperatorFixture.checkFails is true, it > should execute the query and check runtime failure, but currently it ignores > this, and only checks the parse and validation failure. > When fix this, there are 4 failed test cases in CalciteSqlOperatorTest. > At last, this issue was found when to implement `BIT_GET` function in > CALCITE-5848. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CALCITE-5921) SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure
[
https://issues.apache.org/jira/browse/CALCITE-5921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruben Q L resolved CALCITE-5921.
Resolution: Fixed
Fixed via
[{{0bec957}}|https://github.com/apache/calcite/commit/0bec957071468a2e54a22519290ac101a752fcad]
Thanks [~Runking] and [~mbudiu] for your work on this one!
> SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure
> ---
>
> Key: CALCITE-5921
> URL: https://issues.apache.org/jira/browse/CALCITE-5921
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Runkang He
>Assignee: Runkang He
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure.
> See more in [code
> line|https://github.com/apache/calcite/blob/50c3edfc3d6630528ab51fe836bd50df82cc7db8/testkit/src/main/java/org/apache/calcite/test/SqlOperatorFixtureImpl.java#L160].
> When the parameter `runtime` of SqlOperatorFixture.checkFails is true, it
> should execute the query and check runtime failure, but currently it ignores
> this, and only checks the parse and validation failure.
> When fix this, there are 4 failed test cases in CalciteSqlOperatorTest.
> At last, this issue was found when to implement `BIT_GET` function in
> CALCITE-5848.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5921) SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure
[ https://issues.apache.org/jira/browse/CALCITE-5921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ruben Q L updated CALCITE-5921: --- Fix Version/s: 1.36.0 > SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure > --- > > Key: CALCITE-5921 > URL: https://issues.apache.org/jira/browse/CALCITE-5921 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Runkang He >Assignee: Runkang He >Priority: Major > Labels: pull-request-available > Fix For: 1.36.0 > > > SqlOperatorFixture.checkFails and checkAggFails don't check runtime failure. > See more in [code > line|https://github.com/apache/calcite/blob/50c3edfc3d6630528ab51fe836bd50df82cc7db8/testkit/src/main/java/org/apache/calcite/test/SqlOperatorFixtureImpl.java#L160]. > When the parameter `runtime` of SqlOperatorFixture.checkFails is true, it > should execute the query and check runtime failure, but currently it ignores > this, and only checks the parse and validation failure. > When fix this, there are 4 failed test cases in CalciteSqlOperatorTest. > At last, this issue was found when to implement `BIT_GET` function in > CALCITE-5848. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6070) Incorrect field name after RelFieldTrimmer
[
https://issues.apache.org/jira/browse/CALCITE-6070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779408#comment-17779408
]
ZheHu commented on CALCITE-6070:
BTW, we can also reproduce this case in RelBuilderTest. The RelNode and its
logical plan is as follows:
{code}
RelNode root =
builder.scan("DEPT")
.project(builder.field(0))
.filter(
builder.equals(builder.field("DEPTNO"),
builder.literal(20)))
.project(builder.alias(builder.field(0), "alia"))
.sortLimit(1, 1)
.build();
LogicalSort(offset=[1], fetch=[1])
LogicalFilter(condition=[=($0, 20)])
LogicalProject(DEPTNO=[$0])
LogicalTableScan(table=[[scott, DEPT]])
{code}
> Incorrect field name after RelFieldTrimmer
> --
>
> Key: CALCITE-6070
> URL: https://issues.apache.org/jira/browse/CALCITE-6070
> Project: Calcite
> Issue Type: Wish
> Components: core
>Affects Versions: 1.35.0
>Reporter: ZheHu
>Priority: Minor
>
> Run the following SQL in SqlToRelConverterTest:
> {code}
> select ename as did from emp where ename='a' limit 10
> {code}
> Got planA without RelFieldTrimmer:
> {code}
> LogicalSort(fetch=[10])
> LogicalProject(DID=[$1])
> LogicalFilter(condition=[=($1, 'a')])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> Got planB with RelFieldTrimmer:
> {code}
> LogicalSort(fetch=[10])
> LogicalFilter(condition=[=($0, 'a')])
> LogicalProject(ENAME=[$1])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> However, the column alia DID for ENAME is missing in planB.
> Maybe we can do something about the trimmer when we have other
> purposes(renaming column is the only purpose for this case).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6068) Whitespaces are removed from filter values
[
https://issues.apache.org/jira/browse/CALCITE-6068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779376#comment-17779376
]
Petr Masopust commented on CALCITE-6068:
Suggested casting works. Thank you, I can fix our application now.
Do you fix it in Calcite even for CHARs or do you just close this ticket ?
>From user point of view, I would prefer the same behavior for CHAR and VARCHAR.
> Whitespaces are removed from filter values
> --
>
> Key: CALCITE-6068
> URL: https://issues.apache.org/jira/browse/CALCITE-6068
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Petr Masopust
>Priority: Major
>
> SqlImplementor.java has hardcoded "true" for trimming whitespaces in
> Context.toIn method
> ([https://github.com/apache/calcite/blob/c83ac69111fd9e75af5e3615af29a72284667a4a/core/src/main/java/org/apache/calcite/rel/rel2sql/SqlImplementor.java#L908]).
>
> This makes troubles for our customer who use values like "Value 1 " etc.
> (don't ask me why).
> E.g.
> val filter = relBuilder.`in`(
> opportunityId,
> relBuilder.literal("value 1 "),
> relBuilder.literal("value 2 ")
> )
> is translated to "id" IN ('value 1', 'value 2') WITHOUT spaces at the end.
>
> I don't know why is such trimming implemented but calcite should not touch
> user inputs. Please make this at least configurable because I don't know any
> workaround. Obvious one with OR and equalities is optimized to IN and trimmed
> too.
> Test reproducer is in [https://github.com/pmsgd/calcite5888] repo in AppTest
> as testCalcite6068.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
