Thanks and understood Stamatis. At some point in the future (not in the
context of this RC) it would be nice to bounce around ideas about making
syntax optional. I have no idea what mechanism, if any, might support
something like "iff application has set FLAG_FOO then include the
parsing logic for FOO".
P.S. Please don't read this as a complaint. On the contrary, we love
getting fixes, speed-ups and new syntax and features from Calcite for
free (e.g. QUALIFY recently). And we're appreciative of the acceleration
of the current release, we'd just like to share and test ideas with you.
On 2023/03/14 01:48, Stamatis Zampetakis wrote:
Thanks for reporting this James!
I was checking the code and preparing a more elaborate reply but just saw
that Julian covered many of the things that I wanted to mention under
CALCITE-5575.
Although the problem surfaced with the addition of the new parsing logic in
CALCITE-5469 this is merely a coincidence. Basically any new addition in
the parser could potentially come in conflict with custom extensions in
downstream projects.
Given that the impact of CALCITE-5575 is rather localized (projects using
parser extensions and the existing date/time functions) I will not consider
it as a blocker for 1.34.0 and proceed with the current RC.
The vote closes in ~12 hours, so if somebody wants to change their vote in
the light of CALCITE-5575 please do it ASAP.
Best,
Stamatis
On Mon, Mar 13, 2023 at 1:43 PM James Turton <dz...@apache.org> wrote:
Hi
In the context of this RC, may I ask for comment on CALCITE-5575[1]? I'm
not well enough informed to decide if it is actually a Calcite bug (even
a regression?) but I have the sense that it could be. I've been working
on accommodating Calcite's recently added DATE_DIFF function definition
(CALCITE-5469) in Apache Drill and my attempt to supply alternative
parsing logic for it using the provided builtinFunctionCallMethods did
not appear to take any effect. I may just have made some mistake, but I
also spotted what is described in CALCITE-5575 and which may be
preventing Drill from maintaining its own definition of the this function.
Thanks
James
[1] https://issues.apache.org/jira/browse/CALCITE-5575
On 2023/03/10 13:32, Stamatis Zampetakis wrote:
Hi all,
I have created a build for Apache Calcite 1.34.0, release
candidate 0.
Thanks to everyone who has contributed to this release.
You can read the release notes here:
https://github.com/apache/calcite/blob/calcite-1.34.0-rc0/site/_docs/history.md
The commit to be voted upon:
https://gitbox.apache.org/repos/asf?p=calcite.git;a=commit;h=7dfd641baeb0e1b26dec04da5241c3999fe0ac6a
Its hash is 7dfd641baeb0e1b26dec04da5241c3999fe0ac6a
Tag:
https://github.com/apache/calcite/tree/calcite-1.34.0-rc0
The artifacts to be voted on are located here:
https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-1.34.0-rc0
(revision 60513)
The hashes of the artifacts are as follows:
1b4733229b67e3241329c24c52a79122e1834a4ef1db9c25856281de7e6db8a80a6ae6ac07d28dd05d3ee43c0a79587cc280ebfc6025b4ba3d974e38e804b47b
*apache-calcite-1.34.0-src.tar.gz
A staged Maven repository is available for review at:
https://repository.apache.org/content/repositories/orgapachecalcite-1200/org/apache/calcite/
Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/zabetak.asc
https://www.apache.org/dist/calcite/KEYS
To create the jars and test Apache Calcite: "gradle build"
(requires an appropriate Gradle/JDK installation)
Please vote on releasing this package as Apache Calcite 1.34.0.
The vote is open for the next 96 hours (due to the weekend) and passes
if a
majority of at
least three +1 PMC votes are cast.
[ ] +1 Release this package as Apache Calcite 1.34.0
[ ] 0 I don't feel strongly about it, but I'm okay with the release
[ ] -1 Do not release this package because...
Here is my vote:
+1 (binding)
Stamatis
