Re: [ANNOUNCE] New committer: Jiajun Xie
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 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 > > code > > > as > > > well as helping others in the mailing list! He has landed important > > fixes > > > in > > > RelToSqlConverter and more generally in the JDBC storage handler, added > > > new SQL functions, improved the SQL parsers and the metadata handlers, > > and > > > pushed many more high quality contributions in various areas. > > > > > > Jiajun, welcome, thank you for your contributions, and we look forward > to > > > your > > > further interactions with the community! If you wish, please feel free > to > > > tell > > > us more about yourself and what you are working on. > > > > > > As your first commit, please add yourself to the contributors list [1] > > > and the community page will re-generate [2]. > > > > > > Stamatis (on behalf of the Apache Calcite PMC) > > > > > > [1] > > https://github.com/apache/calcite/blob/main/site/_data/contributors.yml > > > > > > [2] https://calcite.apache.org/community/#project-members > > > > > > > > -- > > Best, > Benchao Li >
Re: [ANNOUNCE] New committer: Jiajun Xie
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 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 important > fixes > > in > > RelToSqlConverter and more generally in the JDBC storage handler, added > > new SQL functions, improved the SQL parsers and the metadata handlers, > and > > pushed many more high quality contributions in various areas. > > > > Jiajun, welcome, thank you for your contributions, and we look forward to > > your > > further interactions with the community! If you wish, please feel free to > > tell > > us more about yourself and what you are working on. > > > > As your first commit, please add yourself to the contributors list [1] > > and the community page will re-generate [2]. > > > > Stamatis (on behalf of the Apache Calcite PMC) > > > > [1] > https://github.com/apache/calcite/blob/main/site/_data/contributors.yml > > > > [2] https://calcite.apache.org/community/#project-members > > > -- Best, Benchao Li
Re: [ANNOUNCE] New committer: Jiajun Xie
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 code as well as helping others in the mailing list! He has landed important fixes in RelToSqlConverter and more generally in the JDBC storage handler, added new SQL functions, improved the SQL parsers and the metadata handlers, and pushed many more high quality contributions in various areas. Jiajun, welcome, thank you for your contributions, and we look forward to your further interactions with the community! If you wish, please feel free to tell us more about yourself and what you are working on. As your first commit, please add yourself to the contributors list [1] and the community page will re-generate [2]. Stamatis (on behalf of the Apache Calcite PMC) [1] https://github.com/apache/calcite/blob/main/site/_data/contributors.yml [2] https://calcite.apache.org/community/#project-members
Re: withExpand behavior with ANY/ALL subqueries
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 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 therefore less buggy.) But we will > > accept bug fixes to SqlToRelConverter running in expand=true mode if > > they are clean and simple. > > > > That's quite a big 'if'. I suspect that it's quite hard to make a fix > > without significant changes to SqlToRelConverter. If so, you should > > stop, because we are not likely to accept it. > > > > Calcite committers, > > > > For a while https://issues.apache.org/jira/browse/CALCITE-3870 has > > been open, proposing that expand=false is the default. Should we do > > it? I think it will clarify our position, and make people less likely > > to run into bugs when they use the old expand=true behavior by > > accident. > > > > Julian > > > > > > On Fri, Feb 10, 2023 at 9:57 AM Jonathan Sternberg > > wrote: > > > > > > 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: > > > > > https://github.com/apache/calcite/blob/717eb59a73e2b456266da1af5ff9b881b6f7eeed/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L5319 > > > > > > withExpand = true is the default behavior and, in other cases like > > HAVING, > > > it produces a more desirable plan so I'd prefer to keep withExpand to its > > > default value rather than overriding it. Is there a way to allow > > subqueries > > > to be expanded while also allowing subqueries that can't be expanded to > > > stay as subqueries? Would Calcite be open to a change that allowed this > > > behavior? > > > > > > Thanks. > > > > > > --Jonathan Sternberg > >
Re: withExpand behavior with ANY/ALL subqueries
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 therefore less buggy.) But we will > accept bug fixes to SqlToRelConverter running in expand=true mode if > they are clean and simple. > > That's quite a big 'if'. I suspect that it's quite hard to make a fix > without significant changes to SqlToRelConverter. If so, you should > stop, because we are not likely to accept it. > > Calcite committers, > > For a while https://issues.apache.org/jira/browse/CALCITE-3870 has > been open, proposing that expand=false is the default. Should we do > it? I think it will clarify our position, and make people less likely > to run into bugs when they use the old expand=true behavior by > accident. > > Julian > > > On Fri, Feb 10, 2023 at 9:57 AM Jonathan Sternberg > wrote: > > > > 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: > > > https://github.com/apache/calcite/blob/717eb59a73e2b456266da1af5ff9b881b6f7eeed/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L5319 > > > > withExpand = true is the default behavior and, in other cases like > HAVING, > > it produces a more desirable plan so I'd prefer to keep withExpand to its > > default value rather than overriding it. Is there a way to allow > subqueries > > to be expanded while also allowing subqueries that can't be expanded to > > stay as subqueries? Would Calcite be open to a change that allowed this > > behavior? > > > > Thanks. > > > > --Jonathan Sternberg >
Re: withExpand behavior with ANY/ALL subqueries
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 therefore less buggy.) But we will accept bug fixes to SqlToRelConverter running in expand=true mode if they are clean and simple. That's quite a big 'if'. I suspect that it's quite hard to make a fix without significant changes to SqlToRelConverter. If so, you should stop, because we are not likely to accept it. Calcite committers, For a while https://issues.apache.org/jira/browse/CALCITE-3870 has been open, proposing that expand=false is the default. Should we do it? I think it will clarify our position, and make people less likely to run into bugs when they use the old expand=true behavior by accident. Julian On Fri, Feb 10, 2023 at 9:57 AM Jonathan Sternberg wrote: > > 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: > https://github.com/apache/calcite/blob/717eb59a73e2b456266da1af5ff9b881b6f7eeed/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L5319 > > withExpand = true is the default behavior and, in other cases like HAVING, > it produces a more desirable plan so I'd prefer to keep withExpand to its > default value rather than overriding it. Is there a way to allow subqueries > to be expanded while also allowing subqueries that can't be expanded to > stay as subqueries? Would Calcite be open to a change that allowed this > behavior? > > Thanks. > > --Jonathan Sternberg
[ANNOUNCE] New committer: Jiajun Xie
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 important fixes in RelToSqlConverter and more generally in the JDBC storage handler, added new SQL functions, improved the SQL parsers and the metadata handlers, and pushed many more high quality contributions in various areas. Jiajun, welcome, thank you for your contributions, and we look forward to your further interactions with the community! If you wish, please feel free to tell us more about yourself and what you are working on. As your first commit, please add yourself to the contributors list [1] and the community page will re-generate [2]. Stamatis (on behalf of the Apache Calcite PMC) [1] https://github.com/apache/calcite/blob/main/site/_data/contributors.yml [2] https://calcite.apache.org/community/#project-members
withExpand behavior with ANY/ALL subqueries
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: https://github.com/apache/calcite/blob/717eb59a73e2b456266da1af5ff9b881b6f7eeed/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L5319 withExpand = true is the default behavior and, in other cases like HAVING, it produces a more desirable plan so I'd prefer to keep withExpand to its default value rather than overriding it. Is there a way to allow subqueries to be expanded while also allowing subqueries that can't be expanded to stay as subqueries? Would Calcite be open to a change that allowed this behavior? Thanks. --Jonathan Sternberg
[jira] [Created] (CALCITE-5525) GROUPING_ID() should be rewritten to GROUPING() in some dialects
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
Issue Type: Improvement
Components: core
Reporter: Jiajun Xie
Assignee: Jiajun Xie
Some databases not exists `grouping_id()`, `grouping()` is used as
`grouping_id()`.
- Postgresql
{code:java}
ERROR: function grouping_id(integer, character varying) does not exist
LINE 1: select grouping(id), grouping(name), grouping_id(id, name), ...
^
HINT: No function matches the given name and argument types. You might need to
add explicit type casts
{code}
- Presto
{code:java}
Function grouping_id not registered
{code}
Here is a simple query, `grouping_id()` is a legal function in Spark.
{code:java}
select a,
b,
count(*),
grouping(a) ga,
grouping(b) gb,
grouping_id(a, b)
from (
select 1 as a, 2 as b
)
group by grouping sets((a, b), (b), ())
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: Avatica "standalone-server" connection problem
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 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 message that I see in console is saying that Server was launched
Successfully on specific port.
However, when I try to connect to standalone-server from client application I
receive:
No response for
{"request":"openConnection","connectionId":"9faf5639-7c97-48ab-9062-6ba9e0c1e5f0","info":{"password":"...","user":"..."}}
Could you please point me to the guidelines of how the standalone-server should
be started?
(I`m suspecting the server settings, because even if I disable postgreDB service -
console message is still saying "server started Successfully")
Thanks in advance,
Vladislav
Elsevier Information Systems GmbH
Address (Firmensitz): Franklinstr. 61-63, 60486 Frankfurt, Germany
Registration (Registergericht): Amtsgericht Frankfurt am Main, HRB 57356,
UST-ID-Nr.(VAT ID): DE813757333
Managing Directors (Geschaeftsfuehrer): Cameron Ross, Olaf Lodbrok
Avatica "standalone-server" connection problem
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 message that I see in console is saying that Server was launched
Successfully on specific port.
However, when I try to connect to standalone-server from client application I
receive:
No response for
{"request":"openConnection","connectionId":"9faf5639-7c97-48ab-9062-6ba9e0c1e5f0","info":{"password":"...","user":"..."}}
Could you please point me to the guidelines of how the standalone-server should
be started?
(I`m suspecting the server settings, because even if I disable postgreDB
service - console message is still saying "server started Successfully")
Thanks in advance,
Vladislav
Elsevier Information Systems GmbH
Address (Firmensitz): Franklinstr. 61-63, 60486 Frankfurt, Germany
Registration (Registergericht): Amtsgericht Frankfurt am Main, HRB 57356,
UST-ID-Nr.(VAT ID): DE813757333
Managing Directors (Geschaeftsfuehrer): Cameron Ross, Olaf Lodbrok
[jira] [Created] (CALCITE-5524) JDBC adapter generates LIMIT, OFFSET in wrong order for Presto dialect
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: Calcite
Issue Type: Bug
Reporter: Julian Hyde
JDBC adapter generates LIMIT, OFFSET in wrong order for Presto dialect.
The presto paging statement should be:
{code}
SELECT * FROM db1.tb1 offset 100 limit 20;
{code}
The original version defaults to spelling limit first and then offset, which
does not conform to presto syntax.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
