Congratulations Jiajun, very well deserved, looking forward to work more
with you in the future!
Best regards,
Alessandro
On Sat 11 Feb 2023, 03:06 Benchao Li, wrote:
> Congratulations, Jiajun. Welcome on board.
>
> Francis Chuang 于2023年2月11日周六 09:51写道：
>
> > Congrats, Jiajun!
> >
> > On
Congratulations, Jiajun. Welcome on board.
Francis Chuang 于2023年2月11日周六 09:51写道：
> Congrats, Jiajun!
>
> On 11/02/2023 8:09 am, Stamatis Zampetakis wrote:
> > Apache Calcite's Project Management Committee (PMC) has invited Jiajun
> Xie
> > to
> > become a committer, and we are pleased to
Congrats, Jiajun!
On 11/02/2023 8:09 am, Stamatis Zampetakis wrote:
Apache Calcite's Project Management Committee (PMC) has invited Jiajun Xie
to
become a committer, and we are pleased to announce that they have accepted.
Jiajun has been doing some great work for the project both in terms of
Agreed. This is a breaking change.
I've started work in a branch:
https://github.com/julianhyde/calcite/tree/3870-sql2rel-expand-false
On Fri, Feb 10, 2023 at 1:47 PM Stamatis Zampetakis wrote:
>
> It totally makes sense to have expand=false since this is what we recommend.
>
> It can be a
It totally makes sense to have expand=false since this is what we recommend.
It can be a notable change though for those using SqlToRelConverter as it
is so we have to at least put it in a prominent place in the release notes.
Best,
Stamatis
On Fri, Feb 10, 2023 at 10:32 PM Julian Hyde wrote:
You should definitely log a bug for this. Please do so.
We would prefer that new features in SqlToRelConverter are developed
with expand=false. (Rationale: Keeping subqueries as RexSubQuery
expressions allows us to handle them later, via a planner rule, which
makes the logic more composable and
Apache Calcite's Project Management Committee (PMC) has invited Jiajun Xie
to
become a committer, and we are pleased to announce that they have accepted.
Jiajun has been doing some great work for the project both in terms of code
as
well as helping others in the mailing list! He has landed
Hi,
I'm using Calcite for a project and am attempting to implement the behavior
for ANY/ALL such as:
SELECT ... FROM ... WHERE a = ANY(SELECT ...)
When I attempt to have Calcite create a plan for this query, I get the
runtime exception from here:
Jiajun Xie created CALCITE-5525:
---
Summary: GROUPING_ID() should be rewritten to GROUPING() in some
dialects
Key: CALCITE-5525
URL: https://issues.apache.org/jira/browse/CALCITE-5525
Project: Calcite
Hey Vladislav,
I believe you posted this in another thread earlier today. If you have
not received my reply, you can read it here:
https://lists.apache.org/thread/lz3mdmo8y70d2lp8xlhfq1vbrf88gdmr
Francis
On 10/02/2023 8:04 pm, Matyushevski, Vladislav (ELS-CON) wrote:
Hello!
I`m new to
Hello!
I`m new to Avatica and trying to use "avatica-standalone-server-1.23.0.jar" to
check how my client is working with it.
In order to launch the standalone jar I`m using this command:
"java -jar avatica-standalone-server-1.23.0.jar -u -u
jdbc:postgresql://localhost:5432/db_name"
And
Julian Hyde created CALCITE-5524:
Summary: JDBC adapter generates LIMIT, OFFSET in wrong order for
Presto dialect
Key: CALCITE-5524
URL: https://issues.apache.org/jira/browse/CALCITE-5524
Project:
12 matches
Mail list logo
