[jira] [Updated] (CALCITE-6364) HttpClient SPENGO support is deprecated
[ https://issues.apache.org/jira/browse/CALCITE-6364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth updated CALCITE-6364: - Description: The Avatica Java client depends on Apache HttpClient's Kerberos/SPNEGO implementation. According to HTTPCLIENT-1625 that implementation is not secure, and is deprecated in newer versions. Unfortunately, HTTPCLIENT-1625 is very scant on details, and since the reason given for deprecation is the lack of time to fix it, it is likely not a trivial fix. Unfortunately, Avatica depends heavily on httpclient, and replacing it would it would be a big job. While Avatica in theory has a configurable Http Client implementation, the only non-httpclient implementation is more of a POC, and does not support ANY authentication methods. I can see these options: 1. Find an another http client library, and use it in Avatica 2. Copy the SPENGO auth code from httpclient, and fix it in Avatica 3. Fix the SPENGO auth code in httpclient. 4. Re-Implement SPENGO auth in Avatica (Hadoop does something like that, though I'm, not sure how good that is) was: The Avatica Java client depends on Apache HttpClient's Kerberos/SPNEGO implementation. According to HTTPCLIENT-1625 that implementation is not secure, and is deprecated in newer versions. Unfortunately, HTTPCLIENT-1625 is very scant on details, and since the reason given for deprecation is the lack of time to fix it, it is likely not a trivial fix. Unfortunately, Avatica depends heavily on httpclient, and replacing it would it would be a big job. While Avatica in theory has a configurable Http Client implementation, the only non-httpclient implementation is more of a POC, and does not support ANY authentication methods. I can see these options: 1. Find an another http client library, and use it in Avatica 2. Copy the SPENGO auth code from httpclient, and fix it in Avatica 3. Fix the SPENGO auth code in httpclient. > HttpClient SPENGO support is deprecated > --- > > Key: CALCITE-6364 > URL: https://issues.apache.org/jira/browse/CALCITE-6364 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Istvan Toth >Priority: Critical > > The Avatica Java client depends on Apache HttpClient's Kerberos/SPNEGO > implementation. > According to HTTPCLIENT-1625 that implementation is not secure, and is > deprecated in newer versions. > Unfortunately, HTTPCLIENT-1625 is very scant on details, and since the reason > given for deprecation is the lack of time to fix it, it is likely not a > trivial fix. > Unfortunately, Avatica depends heavily on httpclient, and replacing it would > it would be a big job. > While Avatica in theory has a configurable Http Client implementation, the > only non-httpclient implementation is more of a POC, and does not support ANY > authentication methods. > I can see these options: > 1. Find an another http client library, and use it in Avatica > 2. Copy the SPENGO auth code from httpclient, and fix it in Avatica > 3. Fix the SPENGO auth code in httpclient. > 4. Re-Implement SPENGO auth in Avatica (Hadoop does something like that, > though I'm, not sure how good that is) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6364) HttpClient SPENGO support is deprecated
[ https://issues.apache.org/jira/browse/CALCITE-6364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838470#comment-17838470 ] Istvan Toth commented on CALCITE-6364: -- 5.3 even removes SPNEGO from DefaultAuthenticationStrategy, so that a custom AuthenticationStrategy is required to use it. > HttpClient SPENGO support is deprecated > --- > > Key: CALCITE-6364 > URL: https://issues.apache.org/jira/browse/CALCITE-6364 > Project: Calcite > Issue Type: Bug > Components: avatica >Reporter: Istvan Toth >Priority: Critical > > The Avatica Java client depends on Apache HttpClient's Kerberos/SPNEGO > implementation. > According to HTTPCLIENT-1625 that implementation is not secure, and is > deprecated in newer versions. > Unfortunately, HTTPCLIENT-1625 is very scant on details, and since the reason > given for deprecation is the lack of time to fix it, it is likely not a > trivial fix. > Unfortunately, Avatica depends heavily on httpclient, and replacing it would > it would be a big job. > While Avatica in theory has a configurable Http Client implementation, the > only non-httpclient implementation is more of a POC, and does not support ANY > authentication methods. > I can see these options: > 1. Find an another http client library, and use it in Avatica > 2. Copy the SPENGO auth code from httpclient, and fix it in Avatica > 3. Fix the SPENGO auth code in httpclient. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6363) Introduce a rule to derive more filters from inner join condition
[
https://issues.apache.org/jira/browse/CALCITE-6363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838430#comment-17838430
]
Benchao Li commented on CALCITE-6363:
-
bq. Thanks for finding JoinConditionPushRule (CALCITE-5073). This case seems to
be a generalization of that. Maybe the logic should be added to
JoinConditionPushRule. What's your opinion, Benchao Li?
[~julianhyde] I agree with it. CALCITE-5073 has done some preliminary work
towards this optimization (construct equal sets for columns, derive equal
conditions from equal sets).
> Introduce a rule to derive more filters from inner join condition
> -
>
> Key: CALCITE-6363
> URL: https://issues.apache.org/jira/browse/CALCITE-6363
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: ruanhui
>Priority: Minor
> Labels: pull-request-available
>
> Sometimes we can infer more predicates from inner Join , for example, in the
> query
> SELECT * FROM ta INNER JOIN tb ON ta.x = tb.y WHERE ta.x > 10
> we can infer condition tb.y > 10 and we can push it down to the table tb.
> In this way, it is possible to reduce the amount of data involved in the Join.
> To achieve this, here is my idea.
> The core data strucature is two Multimap:
> predicateMap : a map for inputRef to corresponding predicate such as: $1 ->
> [$1 > 10, $1 < 20, $1 = $2]
> equivalenceMap : a map for inputRef to corresponding equivalent values or
> inputRefs such as: $1 -> [$2, 1]
> The filter derivation is divided into 4 steps:
> 1. construct predicate map and equivalence map by traversing all conjunctions
> in the condition
> 2. search map and rewrite predicates with equivalent inputRefs or literals
> 2.1 find all inputRefs that are equivalent to the current inputRef, and then
> rewrite all predicates involving equivalent inputRefs using inputRef, for
> example if we have inputRef $1 = equivInputRef $2, then we can rewrite \{$2 =
> 10} to \{$1 = 10}.
> 2.2 find all predicates involving current inputRef. If any predicate refers
> to another inputRef, rewrite the predicate with the literal/constant
> equivalent to that inputRef, such as: if we have inputRef \{$1 > $2} and \{$2
> = 10} then we can infer new condition \{$1 > 10}.
> 2.3 derive new predicates based on equivalence relation in equivalenceMultimap
> 3. compose all original predicates and derived predicates
> 4. simplify expression such as range merging, like \{$1 > 10 AND $1 > 20} =>
> \{$1 > 20}, \{$1 > $2 AND $1 > $2} => \{$1 > $2}
> Anyone interested in this, please feel free to comment on this issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5289) Assertion failure in MultiJoinOptimizeBushyRule
[
https://issues.apache.org/jira/browse/CALCITE-5289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-5289:
Labels: pull-request-available (was: )
> Assertion failure in MultiJoinOptimizeBushyRule
> ---
>
> Key: CALCITE-5289
> URL: https://issues.apache.org/jira/browse/CALCITE-5289
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.32.0, 1.35.0
>Reporter: Mihai Budiu
>Assignee: Mou Wu
>Priority: Minor
> Labels: pull-request-available
>
> The reproduction is easy: just modify the following test case from
> PlannerTest.java:
>
> — a/core/src/test/java/org/apache/calcite/tools/PlannerTest.java
> +++ b/core/src/test/java/org/apache/calcite/tools/PlannerTest.java
> {}@@ -1005,7 +1005,7 @@ private void checkJoinNWay(int n) throws
> Exception {{}
> {{private void checkHeuristic(String sql, String expected) throws Exception
> {}}
> {{ Planner planner = getPlanner(null,}}
> {{- Programs.heuristicJoinOrder(Programs.RULE_SET, false, 0));}}
> {{+ Programs.heuristicJoinOrder(Programs.RULE_SET, true, 0));}}
> {{ SqlNode parse = planner.parse(sql);}}
> {{ SqlNode validate = planner.validate(parse);}}
> {{ RelNode convert = planner.rel(validate).rel;}}
>
> Then the test fails with the exception shown below. This happens with the
> latest version of calcite, the main branch.
> It looks like the rule does not account for the fact that outer joins can
> produce results with a different nullability than the input relations.
> The exception can be triggered even for very simple outer join queries, e.g.:
> SELECT T1.COL3 FROM T AS T1 LEFT JOIN T AS T2 ON T1.COL1 = T2.COL5
>
> The only workaround I found is to make sure this rule is never applied when a
> query contains an outer join.
>
> Here is the Java stack trace:
> {{java.lang.RuntimeException: Error while applying rule
> MultiJoinOptimizeBushyRule, args
> [rel#44:MultiJoin.NONE.[](input#0=RelSubset#42,input#1=RelSubset#43,joinFilter=true,isFullOuterJoin=false,joinTypes=[RIGHT,
> INNER],outerJoinConditions=[=($0, $10), NULL],projFields=[ALL, ALL])]}}
>
> {{ at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:250)}}
> {{ at
> org.apache.calcite.plan.volcano.IterativeRuleDriver.drive(IterativeRuleDriver.java:59)}}
> {{ at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:523)}}
> {{ at
> org.apache.calcite.tools.Programs$RuleSetProgram.run(Programs.java:318)}}
> {{ at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:337)}}
> {{ at
> org.apache.calcite.tools.Programs.lambda$heuristicJoinOrder$1(Programs.java:223)}}
> {{ at
> org.apache.calcite.prepare.PlannerImpl.transform(PlannerImpl.java:373)}}
> {{ at
> org.apache.calcite.tools.PlannerTest.checkHeuristic(PlannerTest.java:1014)}}
> {{ at
> org.apache.calcite.tools.PlannerTest.testHeuristicRightJoin(PlannerTest.java:1003)}}
> {{ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)}}
> {{ at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)}}
> {{ at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)}}
> {{ at java.lang.reflect.Method.invoke(Method.java:498)}}
> {{ at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:725)}}
> {{ at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)}}
> {{ at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)}}
> {{ at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:149)}}
> {{ at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:140)}}
> {{ at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:84)}}
> {{ at
> org.junit.jupiter.engine.execution.ExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(ExecutableInvoker.java:115)}}
> {{ at
> org.junit.jupiter.engine.execution.ExecutableInvoker.lambda$invoke$0(ExecutableInvoker.java:105)}}
> {{ at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)}}
> {{ at
>
[jira] [Resolved] (CALCITE-6345) Intervals with more than 100 years are not supported
[
https://issues.apache.org/jira/browse/CALCITE-6345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mihai Budiu resolved CALCITE-6345.
--
Fix Version/s: 1.37.0
Resolution: Fixed
Fixed in
https://github.com/apache/calcite/commit/b4bcd3b69a39ac40974690d1bd4ea08f364638ce
> Intervals with more than 100 years are not supported
>
>
> Key: CALCITE-6345
> URL: https://issues.apache.org/jira/browse/CALCITE-6345
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> Adding the following SqlValidatorTest:
> {code:java}
> expr("INTERVAL '100-2' YEAR TO MONTH").assertInterval(is(122L));
> {code}
> causes the following exception:
> {code}
> org.apache.calcite.runtime.CalciteContextException: From line 1, column 9 to
> line 1, column 38: Interval field value 100 exceeds precision of YEAR(2) field
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:507)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:948)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:933)
> at
> org.apache.calcite.sql.SqlIntervalQualifier.fieldExceedsPrecisionException(SqlIntervalQualifier.java:1355)
> at
> org.apache.calcite.sql.SqlIntervalQualifier.checkLeadFieldInRange(SqlIntervalQualifier.java:475)
> at
> org.apache.calcite.sql.SqlIntervalQualifier.evaluateIntervalLiteralAsYearToMonth(SqlIntervalQualifier.java:626)
> at
> org.apache.calcite.sql.SqlIntervalQualifier.evaluateIntervalLiteral(SqlIntervalQualifier.java:1293)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateLiteral(SqlValidatorImpl.java:3429)
> {code}
> The spec does not limit years to 2 digits, so I don't know where the YEAR(2)
> time is coming from.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6371) Add ability to configure RexExecutable behavior on exceptions
[
https://issues.apache.org/jira/browse/CALCITE-6371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838299#comment-17838299
]
Mihai Budiu commented on CALCITE-6371:
--
Strictly speaking these are not literals, but expressions where all
subexpressions have compile-time constant values.
There is no literal representing 1/0.
People may introduce intentionally such expressions in the code, for example to
guard against incorrect input data. There is no "assert" in SQL, so this is one
way you could produce runtime errors.
On the other hand, a warning may be in order, but Calcite does not have any
mechanism for reporting warnings to the user. That would be something
worthwhile adding and using for this purpose. Coupled with a flag like -Wall
this could turn into the feature you are asking for.
> Add ability to configure RexExecutable behavior on exceptions
> -
>
> Key: CALCITE-6371
> URL: https://issues.apache.org/jira/browse/CALCITE-6371
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.36.0
>Reporter: Claude Brisson
>Priority: Major
>
> The current behavior of Calcite's {{RexExecutable}} constant folding class is
> to eat all exceptions encountered during reduction. The underlying reason, as
> far as I understand it, is that even if Calcite can't reduce an expression,
> maybe the evaluation engine will be able to do it. Fair enough.
> But it would be useful to be able to chose to let some exceptions go through.
> One good example is {{ArithmeticException}} errors. They occur on divisions
> by zero, negative logarithms, etc. and we may want to avoid the downstream
> evaluation engine to receive such invalid expressions.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6373) Distinct optimization produces broken sql query
[
https://issues.apache.org/jira/browse/CALCITE-6373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838248#comment-17838248
]
Julian Hyde commented on CALCITE-6373:
--
I agree that any SQL-to-SQL transformation that alters the number or order of
parameters (question marks in the text) is invalid.
However, I don’t think the “distinct optimization” is to blame. The rel-to-SQL
process should ensure that parameters are output in sequential order. I don’t
know how to do that in general; is it possible to output PL/SQL or pgsql that
assigns the parameters to variables, then uses those variables multiple times?
> Distinct optimization produces broken sql query
> ---
>
> Key: CALCITE-6373
> URL: https://issues.apache.org/jira/browse/CALCITE-6373
> Project: Calcite
> Issue Type: Bug
> Components: core, jdbc-adapter
>Affects Versions: 1.36.0
>Reporter: Corvin Kuebler
>Priority: Major
>
> Can be reproduced with the following test in JDBCTests:
> {code:java}
> String statement = "SELECT\n" +
>" DISTINCT \"case-column\"\n" +
>"FROM (\n" +
>" SELECT \n" +
>" CASE\n" +
>" WHEN CAST(? AS VARCHAR) = \"ENAME\" THEN CAST(?
> AS INTEGER)\n" +
>" ELSE CAST(? AS INTEGER)\n" +
>" END AS \"case-column\"\n" +
>" FROM \"EMP\")";
> CalciteAssert.model(JdbcTest.SCOTT_MODEL)
> .query(statement)
> .consumesPreparedStatement(p -> {
> p.setString(1, "name");
> p.setInt(2, 2);
> p.setInt(3, 1);
> })
> .planHasSql("");
> {code}
> Lets assume the following statement is passed through calcite:
> Before:
> {code:java}
> SELECT
> DISTINCT "case-column"
> FROM
>SELECT
>CASE
> WHEN CAST(? AS VARCHAR) = "store_name" THEN CAST(? AS INTEGER)
> ELSE CAST(? AS INTEGER)
> END AS "case-column"
>FROM "foodmart"."store"
> {code}
> After:
> {code:java}
> SELECT
>CASE
> WHEN ? = "ENAME" THEN ?
> ELSE ?
>END AS "case-column"
> FROM
>"SCOTT"."EMP"
> GROUP BY
>CASE
> WHEN ? = "ENAME" THEN ?
> ELSE ?
>END
> {code}
> The produced statement hast two issues:
> 1. The missing casts (see also
> https://issues.apache.org/jira/browse/CALCITE-6346)
> 2. Instead of pushing the DISTINCT it is replaced with a GROUP BY. This is
> usually fine *but* since the field is a case statement containing dynamic
> parameters it is not.
> During sql syntax evaluation the database will give an error (the field in
> the select is not contained in group by). This is because the dynamic
> parameters are not evaluated during sql syntax evaluation.
> I think this could be fixed by adding an alias to the field in the select
> clause and referencing it in the group by clause instead of duplicating the
> case statement and the dynamic parameters.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CALCITE-5622) Cast is lost from plan to postgres statement
[
https://issues.apache.org/jira/browse/CALCITE-5622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Corvin Kuebler closed CALCITE-5622.
---
Resolution: Fixed
> Cast is lost from plan to postgres statement
>
>
> Key: CALCITE-5622
> URL: https://issues.apache.org/jira/browse/CALCITE-5622
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.34.0
>Reporter: Corvin Kuebler
>Priority: Major
>
> Hey,
> I found an issue with translation from plan to postgres sql statement.
> Adding the following Test to `JdbcAdapterTests.java` exposes the bug:
> {code:java}
> @Test void testDateCastPlan() {
> final String sql = "SELECT CAST(T1.\"brand_name\" AS DATE)\n"
> + "FROM \"foodmart\".\"product\" AS T1\n"
> + "WHERE CAST(T1.\"brand_name\" AS DATE) = CAST('2023-03-27' AS DATE)";
> CalciteAssert.model(FoodmartSchema.FOODMART_MODEL)
> .query(sql)
> .explainContains("PLAN=JdbcToEnumerableConverter\n" +
> " JdbcProject(EXPR$0=[CAST($2):DATE])\n" +
> " JdbcFilter(condition=[=(CAST($2):DATE, 2023-03-27)])\n" +
> " JdbcTableScan(table=[[foodmart, product]])\n\n")
> .runs()
> .enable(CalciteAssert.DB == DatabaseInstance.POSTGRESQL)
> .planHasSql("SELECT CAST(\"brand_name\" AS DATE)\n" +
> "FROM \"foodmart\".\"product\"\n" +
> "CAST(\"brand_name\" AS DATE)= DATE '2023-03-27'");
> }{code}
>
> The plan contains the cast of the column to DATE type. The resulting SQL
> Statement however does not contain the cast.
> The test fails in run, as the column I'm trying to cast does not contain date
> values but the sql that is being sent to postgres is already wrong.
>
> I'd be happy if you could take a look at it.
>
> Best regards,
> Corvin
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5622) Cast is lost from plan to postgres statement
[
https://issues.apache.org/jira/browse/CALCITE-5622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838213#comment-17838213
]
Corvin Kuebler commented on CALCITE-5622:
-
Its been a while, I even forgot I created this.
Since we recently ran into similar issues I am closing this in favor of
https://issues.apache.org/jira/projects/CALCITE/issues/CALCITE-6346
> Cast is lost from plan to postgres statement
>
>
> Key: CALCITE-5622
> URL: https://issues.apache.org/jira/browse/CALCITE-5622
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
>Affects Versions: 1.34.0
>Reporter: Corvin Kuebler
>Priority: Major
>
> Hey,
> I found an issue with translation from plan to postgres sql statement.
> Adding the following Test to `JdbcAdapterTests.java` exposes the bug:
> {code:java}
> @Test void testDateCastPlan() {
> final String sql = "SELECT CAST(T1.\"brand_name\" AS DATE)\n"
> + "FROM \"foodmart\".\"product\" AS T1\n"
> + "WHERE CAST(T1.\"brand_name\" AS DATE) = CAST('2023-03-27' AS DATE)";
> CalciteAssert.model(FoodmartSchema.FOODMART_MODEL)
> .query(sql)
> .explainContains("PLAN=JdbcToEnumerableConverter\n" +
> " JdbcProject(EXPR$0=[CAST($2):DATE])\n" +
> " JdbcFilter(condition=[=(CAST($2):DATE, 2023-03-27)])\n" +
> " JdbcTableScan(table=[[foodmart, product]])\n\n")
> .runs()
> .enable(CalciteAssert.DB == DatabaseInstance.POSTGRESQL)
> .planHasSql("SELECT CAST(\"brand_name\" AS DATE)\n" +
> "FROM \"foodmart\".\"product\"\n" +
> "CAST(\"brand_name\" AS DATE)= DATE '2023-03-27'");
> }{code}
>
> The plan contains the cast of the column to DATE type. The resulting SQL
> Statement however does not contain the cast.
> The test fails in run, as the column I'm trying to cast does not contain date
> values but the sql that is being sent to postgres is already wrong.
>
> I'd be happy if you could take a look at it.
>
> Best regards,
> Corvin
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6373) Distinct optimization produces broken sql query
Corvin Kuebler created CALCITE-6373:
---
Summary: Distinct optimization produces broken sql query
Key: CALCITE-6373
URL: https://issues.apache.org/jira/browse/CALCITE-6373
Project: Calcite
Issue Type: Bug
Components: core, jdbc-adapter
Affects Versions: 1.36.0
Reporter: Corvin Kuebler
Can be reproduced with the following test in JDBCTests:
{code:java}
String statement = "SELECT\n" +
" DISTINCT \"case-column\"\n" +
"FROM (\n" +
" SELECT \n" +
" CASE\n" +
" WHEN CAST(? AS VARCHAR) = \"ENAME\" THEN CAST(?
AS INTEGER)\n" +
" ELSE CAST(? AS INTEGER)\n" +
" END AS \"case-column\"\n" +
" FROM \"EMP\")";
CalciteAssert.model(JdbcTest.SCOTT_MODEL)
.query(statement)
.consumesPreparedStatement(p -> {
p.setString(1, "name");
p.setInt(2, 2);
p.setInt(3, 1);
})
.planHasSql("");
{code}
Lets assume the following statement is passed through calcite:
Before:
{code:java}
SELECT
DISTINCT "case-column"
FROM
SELECT
CASE
WHEN CAST(? AS VARCHAR) = "store_name" THEN CAST(? AS INTEGER)
ELSE CAST(? AS INTEGER)
END AS "case-column"
FROM "foodmart"."store"
{code}
After:
{code:java}
SELECT
CASE
WHEN ? = "ENAME" THEN ?
ELSE ?
END AS "case-column"
FROM
"SCOTT"."EMP"
GROUP BY
CASE
WHEN ? = "ENAME" THEN ?
ELSE ?
END
{code}
The produced statement hast two issues:
1. The missing casts (see also
https://issues.apache.org/jira/browse/CALCITE-6346)
2. Instead of pushing the DISTINCT it is replaced with a GROUP BY. This is
usually fine *but* since the field is a case statement containing dynamic
parameters it is not.
During sql syntax evaluation the database will give an error (the field in the
select is not contained in group by). This is because the dynamic parameters
are not evaluated during sql syntax evaluation.
I think this could be fixed by adding an alias to the field in the select
clause and referencing it in the group by clause instead of duplicating the
case statement and the dynamic parameters.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6371) Add ability to configure RexExecutable behavior on exceptions
[
https://issues.apache.org/jira/browse/CALCITE-6371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838087#comment-17838087
]
Claude Brisson commented on CALCITE-6371:
-
We're speaking about literals, here. A perfectly legitimate policy can be to
consider {{1/0}} as an invalid literal, and to refuse to process a query
containing it, even if its evaluation can somehow be evicted down the line.
> Add ability to configure RexExecutable behavior on exceptions
> -
>
> Key: CALCITE-6371
> URL: https://issues.apache.org/jira/browse/CALCITE-6371
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.36.0
>Reporter: Claude Brisson
>Priority: Major
>
> The current behavior of Calcite's {{RexExecutable}} constant folding class is
> to eat all exceptions encountered during reduction. The underlying reason, as
> far as I understand it, is that even if Calcite can't reduce an expression,
> maybe the evaluation engine will be able to do it. Fair enough.
> But it would be useful to be able to chose to let some exceptions go through.
> One good example is {{ArithmeticException}} errors. They occur on divisions
> by zero, negative logarithms, etc. and we may want to avoid the downstream
> evaluation engine to receive such invalid expressions.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6265) Type coercion is failing for numeric values in prepared statements
[
https://issues.apache.org/jira/browse/CALCITE-6265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838044#comment-17838044
]
Ruben Q L commented on CALCITE-6265:
Thanks for taking care of the merge [~mbudiu]! I confirm my project's tests are
back to stable with the latest Calcite main.
> Type coercion is failing for numeric values in prepared statements
> --
>
> Key: CALCITE-6265
> URL: https://issues.apache.org/jira/browse/CALCITE-6265
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Tim Nieradzik
>Assignee: Ruben Q L
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> Given a column of type {{{}INT{}}}. When providing a {{short}} value as a
> placeholder in a prepared statement, a {{ClassCastException}} is thrown.
> h2. Test case
> {{final String sql =}}
> {{ "select \"empid\" from \"hr\".\"emps\" where \"empid\" in (?, ?)";}}{{
> CalciteAssert.hr()}}
> {{ .query(sql)}}
> {{ .consumesPreparedStatement(p -> {}}
> {{ p.setShort(1, (short) 100);}}
> {{ p.setShort(2, (short) 110);}}
> {{ })}}
> {{ .returnsUnordered("empid=100", "empid=110");}}
> h2. Stack trace
> {{java.lang.ClassCastException: class java.lang.Short cannot be cast to class
> java.lang.Integer (java.lang.Short and java.lang.Integer are in module
> java.base of loader 'bootstrap')}}
> {{ at Baz$1$1.moveNext(Unknown Source)}}
> {{ at
> org.apache.calcite.linq4j.Linq4j$EnumeratorIterator.(Linq4j.java:679)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
