Re: PR Review Request

2022-06-22 Thread Timo Walther
Hi everyone, This is a really great discussion. Thanks for starting it Martijn and your input Jacques! I have been fighting against forking Calcite in Flink for years already. Even when merging forks of Flink that transitively forked Calcite, in the end we were able to resolve conflicts /

Re: [DISCUSS] Deprecate grouped window functions

2020-04-30 Thread Timo Walther
On Fri, Apr 24, 2020 at 1:50 AM Timo Walther wrote: Hi everyone, so far Apache Flink depends on this feature. We are fine with improving the SQL compliance and eventually dropping GROUP BY TUMBLE/HOP/SESSION in the future. However, we would like to give our users some time to migrate

Re: [DISCUSS] Deprecate grouped window functions

2020-04-24 Thread Timo Walther
Hi everyone, so far Apache Flink depends on this feature. We are fine with improving the SQL compliance and eventually dropping GROUP BY TUMBLE/HOP/SESSION in the future. However, we would like to give our users some time to migrate their existing pipelines. What does dropping mean for

Re: [ANNOUNCE] New committer: Sergey Nuyanzin

2018-07-23 Thread Timo Walther
Congratulations Sergey! Am 23.07.18 um 13:33 schrieb Sergey Nuyanzin: Thanks everyone for kind words! It is a great honor for me to become a Calcite committer. A little bit about myself Past few months I have been focusing on Calcite and Flink. I am still learning Calcite's and Avatica's

Re: Confusion about the GeoFunctions

2018-05-24 Thread Timo Walther
Hi Julian, the Flink community is very thankful for the OpenGIS efforts done by the Calcite community and I think both project can benefit from it. As Xingcan mentioned, we are thinking about contributing a GeoOperatorTable similar to SqlStdOperatorTable. We don't want to reimplement the

[jira] [Created] (CALCITE-1867) Allow creating additional SqlGroupFunctions

2017-06-30 Thread Timo Walther (JIRA)
Timo Walther created CALCITE-1867: - Summary: Allow creating additional SqlGroupFunctions Key: CALCITE-1867 URL: https://issues.apache.org/jira/browse/CALCITE-1867 Project: Calcite Issue Type

Nested TUMBLE/HOP/SESSION windows

2017-05-17 Thread Timo Walther
Hi everyone, we are very happy to support TUMBLE/HOP/SESSION in our upcoming Flink 1.3 release. However, there are some problems regarding nested window queries that we would like to discuss with the Calcite community. Take the following query: SELECT rowtime, SUM(x) FROM ( SELECT

Re: TUMBLE/HOP/SESSION_START/END do not resolve time field correctly

2017-04-25 Thread Timo Walther
for that we can copy the class to Flink until the next Calcite release. We did that with other issues in the past, too. Am 25/04/17 um 20:12 schrieb Timo Walther: Thanks for your quick response. Flink does not use the monotonicity property yet and we are are also not using the STREAM keyword. Could

[jira] [Created] (CALCITE-1761) TUMBLE/HOP/SESSION_START/END do not resolve time field correctly

2017-04-25 Thread Timo Walther (JIRA)
Timo Walther created CALCITE-1761: - Summary: TUMBLE/HOP/SESSION_START/END do not resolve time field correctly Key: CALCITE-1761 URL: https://issues.apache.org/jira/browse/CALCITE-1761 Project

Re: TUMBLE/HOP/SESSION_START/END do not resolve time field correctly

2017-04-25 Thread Timo Walther
e Flink. Can you start a separate email thread when you know that timing? On Tue, Apr 25, 2017 at 7:13 AM, Timo Walther <twal...@apache.org> wrote: Hi all, I'm working on integrating START and END for TUMBLE/HOP/SESSION in Flink SQL with logical time indicator columns (e.g. rowtime, p

TUMBLE/HOP/SESSION_START/END do not resolve time field correctly

2017-04-25 Thread Timo Walther
Hi all, I'm working on integrating START and END for TUMBLE/HOP/SESSION in Flink SQL with logical time indicator columns (e.g. rowtime, proctime). It seems there is a bug in the resolution logic of SqlToRelConverter. Since our feature freeze is next week and this feature should be part of

Handling of system attributes in a row

2017-02-15 Thread Timo Walther
Hi everyone, we (from Flink) are currently discussing how we can express time-semantics (event-time or processing-time) in a SQL query. The optimal solution would be to have two system attributes that are part of every table schema/every row data type. We could then access it like `SELECT *

[jira] [Created] (CALCITE-1435) Wrong comparison of TIMESTAMP literals

2016-10-13 Thread Timo Walther (JIRA)
Timo Walther created CALCITE-1435: - Summary: Wrong comparison of TIMESTAMP literals Key: CALCITE-1435 URL: https://issues.apache.org/jira/browse/CALCITE-1435 Project: Calcite Issue Type: Bug