[jira] [Created] (CALCITE-5291) Make Lex policy for BigQuery case insensitive
TJ Banghart created CALCITE-5291: Summary: Make Lex policy for BigQuery case insensitive Key: CALCITE-5291 URL: https://issues.apache.org/jira/browse/CALCITE-5291 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.32.0, 1.31.0, 1.30.0, 1.28.0 Reporter: TJ Banghart Assignee: TJ Banghart -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5290) Add DATE_TRUNC function consistent with Postgres
Julian Hyde created CALCITE-5290:
Summary: Add DATE_TRUNC function consistent with Postgres
Key: CALCITE-5290
URL: https://issues.apache.org/jira/browse/CALCITE-5290
Project: Calcite
Issue Type: Bug
Reporter: Julian Hyde
Add {{DATE_TRUNC}} function consistent with Postgres. Per the
[specification|https://www.postgresql.org/docs/current/functions-datetime.html#FUNCTIONS-DATETIME-TRUNC],
syntax is as follows:
{code}
DATE_TRUNC(, )
{code}
It is a different (and more complex) specification than BigQuery's DATE_TRUNC
(see CALCITE-5180), which has the following syntax:
{code}
DATE_TRUNC(, )
{code}
Postgres DATE_TRUNC would be implemented after CALCITE-5155 and would allow
user-defined time frames in the {{field}} argument.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Going to ApacheCon?
Anyone going to ApacheCon in New Orleans? Would you be interested in a Birds of a Feather (BoaF) session on Monday evening? We should organize one now, before the best rooms are taken. Julian
Re: Parsing PostgreSQL related operators (BEGIN, DISCARD, SHOW TRANSACTION ISOLATION)
Can you elaborate on why Babel is not the right place? (I don’t agree or disagree, but we need to hear justification. Creating another parser would have continuing maintenance cost.) Julian > On Sep 19, 2022, at 2:59 AM, Dmitry Sysolyatin > wrote: > > Hi! > Babel parser can't parse operators like BEGIN, DISCARD, SHOW TRANSACTION > ISOLATION LEVEL and a bunch of other PostgreSQL related operators. I want > to add support for those operators but I have a feeling that babel parser > is not the right place for that. Maybe it is worth it to create a separate > project like `babel-postgres` and extend babel parser ? > > What do you think?
[jira] [Created] (CALCITE-5289) Assertion failure in MultiJoinOptimizeBushyRule
Mihai Budiu created CALCITE-5289:
Summary: 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
Reporter: Mihai Budiu
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
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)}}
{{ at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)}}
{{ at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)}}
{{ at
org.junit.jupiter.engine.execution.ExecutableInvoker.invoke(ExecutableInvoker.java:104)}}
{{ at
org.j
Parsing PostgreSQL related operators (BEGIN, DISCARD, SHOW TRANSACTION ISOLATION)
Hi! Babel parser can't parse operators like BEGIN, DISCARD, SHOW TRANSACTION ISOLATION LEVEL and a bunch of other PostgreSQL related operators. I want to add support for those operators but I have a feeling that babel parser is not the right place for that. Maybe it is worth it to create a separate project like `babel-postgres` and extend babel parser ? What do you think?
[jira] [Created] (CALCITE-5288) Expression '(a > 1 and a < 3) or (a > 2 and a < 4)' cannot be simplified to 'SEARCH(a, Sarg[(1..4)])'
Aleksey Plekhanov created CALCITE-5288:
--
Summary: Expression '(a > 1 and a < 3) or (a > 2 and a < 4)'
cannot be simplified to 'SEARCH(a, Sarg[(1..4)])'
Key: CALCITE-5288
URL: https://issues.apache.org/jira/browse/CALCITE-5288
Project: Calcite
Issue Type: Bug
Reporter: Aleksey Plekhanov
If there is only one range in search/sarg after simplification, the result of
sarg collector is ignored (\{{SargCollector#needToFix()}} method).
Expression {{(a > 1 and a < 3) or (a > 2 and a < 4)}} is simplified to
{{OR(SEARCH(a, Sarg[(1..3)]), SEARCH(a, Sarg[(2..4)]))}} but expected
{{{}SEARCH(a, Sarg[(1..4)]){}}}.
If there are more the one intervals or if open interval exists, expressions
simplified as expected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: Jira project admin privileges
Hi Julian, thanks for answering and confirming that we don't have any bottlenecks there. I agree that PMC members should have privilege if they want to. Best regards, Alessandro On Sat, 17 Sept 2022 at 22:59, Julian Hyde wrote: > The following 15 people are administrators in jira: > > Andrei Sereda > Chunwei Lei > Danny Chen > Francis Chuang > Hasheng Yuan > Hongze Zhang > Jesus Camacho Rogriguez > Josh Elser > Julian Hyde > Kevin Risden > Liya Fan > Michael Mior > Stamatis Zampetakis > Vova Vysotskyi > > In my opinion, any PMC member should be given administrator privileges if > they request. > > Julian > > > > On Sep 17, 2022, at 12:27 AM, Alessandro Solimando < > alessandro.solima...@gmail.com> wrote: > > > > Hello everyone, > > I have noticed that it's always Francis taking care of assigning > > "contributor" permissions to new users, I guess he is the only person > with > > enough privileges to do that? > > > > What do you think if we granted those privileges to the Calcite PMC > members > > at the least (or even committers if you think it would help)? > > > > In this way we can share the load (even if it's minimum) and it's not > > always on Francis to take care of those requests. > > > > Best regards, > > Alessandro > >
