Re: Removing FLOAT

[Julian Hyde]

Treating FLOAT as sugar for REAL would work. I don’t think we can go as far as 
making SqlTypeName.FLOAT deprecated, but we can add checks that it is not used.
 
I’ll note that Java-based SQL engines (Spark, Hive) got the TIMESTAMP type 
wrong because they assumed that it was equivalent to java.sql.Timestamp, and 
they probably made the same mistake with FLOAT, assuming that it was similar to 
Java float. Sadly, the origins of the SQL type are more likely COBOL or PL/1.

On the subject of DECIMAL and NUMERIC. Someday, I would love to support decimal 
floating point numbers (our current floating point numbers are binary, so 
cannot represent 0.1 exactly). Arbitrary precision would be nice (e.g. 
DECIMAL(192, 0)).

Julian

> On Oct 26, 2023, at 3:13 PM, Mihai Budiu  wrote:
> 
> I am only proposing to remove it from the IR.
> The type would still be accepted by the parser, just represented as DOUBLE.
> No SQL programs would need to change. Just treat it the same way DECIMAL and 
> NUMERIC are handled; there is only one representation for both.
> 
> Julian's solution is the first I thought about, and it certainly can be done.
> There are two reasons that I proposed a radical approach:
> 
>  *   if the type isn't there you cannot make mistakes anymore treating it 
> wrong
>  *   even more importantly, if third party users of Calcite (e.g., let's say 
> a system like Spark) assumed that FLOAT is something else (in Spark it's the 
> same as REAL as far as I can tell), they will now find out that their 
> assumption is wrong, and can take corrective actions.
> 
> Both solution would entail a non-trivial amount of work, so I am trying to 
> avoid working on the wrong one.
> 
> Mihai
> 
> 
> From: Julian Hyde 
> Sent: Thursday, October 26, 2023 3:04 PM
> To: dev@calcite.apache.org 
> Subject: Re: Removing FLOAT
> 
> Removing a type that is in the SQL standard is not practical.
> 
> The best way to deal with the confusion is to state the rules again. If there 
> are a few inconsistencies in the code, fix the inconsistencies.
> 
> REAL is a 32 bit float (similar to Java float);
> DOUBLE is a 64 bit float (similar to Java double);
> Use of FLOAT is not recommended, but it is currently equivalent to DOUBLE.
> 
>> On Oct 26, 2023, at 2:51 PM, Paul Jackson 
>>  wrote:
>> 
>> Doesn't having two types help distinguish which type is in the source 
>> database for platforms that support both? A call to 
>> org.apache.calcite.sql.type.SqlTypeName#getNameForJdbcType would lose that 
>> distinction. I don't know offhand whether there are databases that require a 
>> CAST when converting from double to float. Would that be important to know 
>> before deciding?
>> -Paul
>>   On Thursday, October 26, 2023 at 02:02:50 PM EDT, Mihai Budiu 
>>  wrote:
>> 
>> Hello,
>> 
>> It turns out that there is a lot of confusion in Calcite about what FLOAT is.
>> I have filed an issue about it: 
>> https://issues.apache.org/jira/browse/CALCITE-6074
>> 
>> It seems that the intent is for FLOAT to be an exact alias of DOUBLE.
>> If that's the case, we can remove a lot of code and prevent further 
>> confusions by just removing FLOAT as a SqlTypeName and using DOUBLE 
>> everywhere starting in the parser. The situation is very similar with 
>> DECIMAL and NUMERIC.
>> 
>> This will also prevent a lot of bugs in third party code that uses Calcite, 
>> since they cannot misinterpret what FLOAT is.
>> 
>> If you agree that this is the right thing, I will submit a PR which marks 
>> FLOAT as @Deprecated and removes all its uses in the codebase.
>> 
>> Mihai
>> 
> 

Re: Removing FLOAT

[Mihai Budiu]

I am only proposing to remove it from the IR.
The type would still be accepted by the parser, just represented as DOUBLE.
No SQL programs would need to change. Just treat it the same way DECIMAL and 
NUMERIC are handled; there is only one representation for both.

Julian's solution is the first I thought about, and it certainly can be done.
There are two reasons that I proposed a radical approach:

  *   if the type isn't there you cannot make mistakes anymore treating it wrong
  *   even more importantly, if third party users of Calcite (e.g., let's say a 
system like Spark) assumed that FLOAT is something else (in Spark it's the same 
as REAL as far as I can tell), they will now find out that their assumption is 
wrong, and can take corrective actions.

Both solution would entail a non-trivial amount of work, so I am trying to 
avoid working on the wrong one.

Mihai


From: Julian Hyde 
Sent: Thursday, October 26, 2023 3:04 PM
To: dev@calcite.apache.org 
Subject: Re: Removing FLOAT

Removing a type that is in the SQL standard is not practical.

The best way to deal with the confusion is to state the rules again. If there 
are a few inconsistencies in the code, fix the inconsistencies.

REAL is a 32 bit float (similar to Java float);
DOUBLE is a 64 bit float (similar to Java double);
Use of FLOAT is not recommended, but it is currently equivalent to DOUBLE.

> On Oct 26, 2023, at 2:51 PM, Paul Jackson 
>  wrote:
>
> Doesn't having two types help distinguish which type is in the source 
> database for platforms that support both? A call to 
> org.apache.calcite.sql.type.SqlTypeName#getNameForJdbcType would lose that 
> distinction. I don't know offhand whether there are databases that require a 
> CAST when converting from double to float. Would that be important to know 
> before deciding?
> -Paul
>On Thursday, October 26, 2023 at 02:02:50 PM EDT, Mihai Budiu 
>  wrote:
>
> Hello,
>
> It turns out that there is a lot of confusion in Calcite about what FLOAT is.
> I have filed an issue about it: 
> https://issues.apache.org/jira/browse/CALCITE-6074
>
> It seems that the intent is for FLOAT to be an exact alias of DOUBLE.
> If that's the case, we can remove a lot of code and prevent further 
> confusions by just removing FLOAT as a SqlTypeName and using DOUBLE 
> everywhere starting in the parser. The situation is very similar with DECIMAL 
> and NUMERIC.
>
> This will also prevent a lot of bugs in third party code that uses Calcite, 
> since they cannot misinterpret what FLOAT is.
>
> If you agree that this is the right thing, I will submit a PR which marks 
> FLOAT as @Deprecated and removes all its uses in the codebase.
>
> Mihai
>

Re: Removing FLOAT

[Julian Hyde]

Removing a type that is in the SQL standard is not practical.

The best way to deal with the confusion is to state the rules again. If there 
are a few inconsistencies in the code, fix the inconsistencies.

REAL is a 32 bit float (similar to Java float);
DOUBLE is a 64 bit float (similar to Java double);
Use of FLOAT is not recommended, but it is currently equivalent to DOUBLE.

> On Oct 26, 2023, at 2:51 PM, Paul Jackson 
>  wrote:
> 
> Doesn't having two types help distinguish which type is in the source 
> database for platforms that support both? A call to 
> org.apache.calcite.sql.type.SqlTypeName#getNameForJdbcType would lose that 
> distinction. I don't know offhand whether there are databases that require a 
> CAST when converting from double to float. Would that be important to know 
> before deciding?
> -Paul
>On Thursday, October 26, 2023 at 02:02:50 PM EDT, Mihai Budiu 
>  wrote:  
> 
> Hello,
> 
> It turns out that there is a lot of confusion in Calcite about what FLOAT is.
> I have filed an issue about it: 
> https://issues.apache.org/jira/browse/CALCITE-6074
> 
> It seems that the intent is for FLOAT to be an exact alias of DOUBLE.
> If that's the case, we can remove a lot of code and prevent further 
> confusions by just removing FLOAT as a SqlTypeName and using DOUBLE 
> everywhere starting in the parser. The situation is very similar with DECIMAL 
> and NUMERIC.
> 
> This will also prevent a lot of bugs in third party code that uses Calcite, 
> since they cannot misinterpret what FLOAT is.
> 
> If you agree that this is the right thing, I will submit a PR which marks 
> FLOAT as @Deprecated and removes all its uses in the codebase.
> 
> Mihai
> 

Re: Removing FLOAT

[Mihai Budiu]

You are in essence asking whether there can be any difference between FLOAT and 
DOUBLE. If the code generated by Calcite cares, then there can​ be such a 
difference.

However, I believe that Calcite already assumes implicitly that these two types 
are the same. This means that it is very dangerous for other platforms to 
assume that Calcite will keep the types distinct.  But perhaps some pieces in 
Calcite keep the distinction, while others don't, and if you only use the ones 
that keep the distinction, then you are fine.

For example, as far as I can tell, expression simplification assumes that these 
two types are the same.

If Calcite assumes some semantics for some construct (e.g., FLOAT being the 
same as DOUBLE), it is quite brittle for a target platform or user of calcite 
to assume that Calcite won't use this assumption while rewriting the program.

This makes it even more important to write down explicitly the assumptions that 
Calcite makes, e.g., the semantics of types, or the semantics of casts (which 
is an issue I have been working on lately). The existing documentation is too 
sparse to be able to tell. In essence I am asking for a SPEC of the SQL 
language compiled by Calcite. It is fine for Calcite to say "the semantics of 
FLOAT is target-specific", but in that case it should not make optimizations 
assuming that FLOAT is the same as DOUBLE.

Mihai

From: Paul Jackson 
Sent: Thursday, October 26, 2023 2:51 PM
To: dev@calcite.apache.org 
Subject: Re: Removing FLOAT

Doesn't having two types help distinguish which type is in the source database 
for platforms that support both? A call to 
org.apache.calcite.sql.type.SqlTypeName#getNameForJdbcType would lose that 
distinction. I don't know offhand whether there are databases that require a 
CAST when converting from double to float. Would that be important to know 
before deciding?
-Paul
On Thursday, October 26, 2023 at 02:02:50 PM EDT, Mihai Budiu 
 wrote:

 Hello,

It turns out that there is a lot of confusion in Calcite about what FLOAT is.
I have filed an issue about it: 
https://issues.apache.org/jira/browse/CALCITE-6074

It seems that the intent is for FLOAT to be an exact alias of DOUBLE.
If that's the case, we can remove a lot of code and prevent further confusions 
by just removing FLOAT as a SqlTypeName and using DOUBLE everywhere starting in 
the parser. The situation is very similar with DECIMAL and NUMERIC.

This will also prevent a lot of bugs in third party code that uses Calcite, 
since they cannot misinterpret what FLOAT is.

If you agree that this is the right thing, I will submit a PR which marks FLOAT 
as @Deprecated and removes all its uses in the codebase.

Mihai

Re: Removing FLOAT

[Paul Jackson]

 Doesn't having two types help distinguish which type is in the source database 
for platforms that support both? A call to 
org.apache.calcite.sql.type.SqlTypeName#getNameForJdbcType would lose that 
distinction. I don't know offhand whether there are databases that require a 
CAST when converting from double to float. Would that be important to know 
before deciding?
-Paul
On Thursday, October 26, 2023 at 02:02:50 PM EDT, Mihai Budiu 
 wrote:  
 
 Hello,

It turns out that there is a lot of confusion in Calcite about what FLOAT is.
I have filed an issue about it: 
https://issues.apache.org/jira/browse/CALCITE-6074

It seems that the intent is for FLOAT to be an exact alias of DOUBLE.
If that's the case, we can remove a lot of code and prevent further confusions 
by just removing FLOAT as a SqlTypeName and using DOUBLE everywhere starting in 
the parser. The situation is very similar with DECIMAL and NUMERIC.

This will also prevent a lot of bugs in third party code that uses Calcite, 
since they cannot misinterpret what FLOAT is.

If you agree that this is the right thing, I will submit a PR which marks FLOAT 
as @Deprecated and removes all its uses in the codebase.

Mihai

  

Re: [ANNOUNCE] New committer: Mihai Budiu

[Mihai Budiu]

Thank you for your introduction. I have only gotten started with Calcite, so I 
hope to be able to do more. Calcite is a relatively weak as a mineral, but we 
want the software to be rock-solid, since it is really the foundation of many 
other projects.

I have been mostly a researcher, but currently, together with a few other brave 
individuals, we have founded a new start-up, feldera.com, that aims to build a 
streaming query engine that relies on incremental view maintenance for very 
efficient execution. Our engine is programmed in SQL, and we believe that we 
can execute any query in streaming mode, no matter how complex. Calcite is our 
parser and optimizer. We aim to be good open-source citizens, so we contribute 
not only to Calcite, but our runtime engine in Rust 
https://crates.io/crates/dbsp and our compiler backend 
https://github.com/feldera/feldera/tree/main/sql-to-dbsp-compiler are both 
open-source.

Thank you all for your work on Calcite, which made it possible for us to build 
a SQL compiler in a few person-months!

Mihai


From: Stamatis Zampetakis 
Sent: Thursday, October 26, 2023 1:56 AM
To: dev@calcite.apache.org 
Subject: [ANNOUNCE] New committer: Mihai Budiu

Apache Calcite's Project Management Committee (PMC) has invited Mihai
Budiu to become a committer, and we are pleased to announce that he
has accepted.

Mihai has addressed numerous compile and runtime issues in SQL
functions and has made several significant improvements to the test
infrastructure to enhance code coverage, quality, and stability. In
addition to code contributions, Mihai is highly active on the mailing
list, where he answers questions, assists others, and shares ideas for
future improvements. Mihai has also been writing blogs and giving
talks about Calcite at various events and conferences, showcasing
Calcite in both simple and more advanced use cases, which can greatly
contribute to the growth of the community.

Mihai, 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

Build failed in Jenkins: Calcite » Calcite-snapshots #658

[Apache Jenkins Server]

See 


Changes:


--
[...truncated 393.94 KB...]
 13.7sec, org.apache.calcite.test.PigRelOpTest > 
testRank()
  2.4sec, org.apache.calcite.test.PigRelOpTest > 
testAggregate2()
  2.2sec, org.apache.calcite.test.PigRelOpTest > 
testCoGroup()
  2.1sec, org.apache.calcite.test.PigRelOpTest > 
testCubeCube()
 10.8sec, org.apache.calcite.test.PigRelOpTest > 
testJoin2Rels()
  2.9sec, org.apache.calcite.test.PigRelOpTest > 
testAggregate3()
  2.2sec, org.apache.calcite.test.PigRelOpTest > 
testCubeRollup()
  2.4sec, org.apache.calcite.test.PigRelOpTest > 
testForEachNested()
 32.0sec,   35 completed,   0 failed,   0 skipped, 
org.apache.calcite.test.PigRelOpTest
WARNING  32.1sec,   29 completed,   0 failed,   1 
skipped, org.apache.calcite.test.PigRelExTest
WARNING  41.4sec,  106 completed,   0 failed,   2 
skipped, Gradle Test Run :piglet:test

> Task :babel:test
Warning: JDBC driver threw non-SQLException
Warning: JDBC driver threw non-SQLException
Warning: JDBC driver threw non-SQLException
Warning: JDBC driver threw non-SQLException
Warning: JDBC driver threw non-SQLException
Warning: JDBC driver threw non-SQLException
Warning: JDBC driver threw non-SQLException
 44.6sec, org.apache.calcite.test.BabelQuidemTest > 
test(String)[1], [1] sql/big-query.iq
  6.7sec, org.apache.calcite.test.BabelQuidemTest > 
test(String)[5], [5] sql/redshift.iq
 52.9sec,5 completed,   0 failed,   0 skipped, 
org.apache.calcite.test.BabelQuidemTest > test(String)
 53.2sec,5 completed,   0 failed,   0 skipped, 
org.apache.calcite.test.BabelQuidemTest
WARNING  61.4sec,  502 completed,   0 failed,   4 
skipped, Gradle Test Run :babel:test

> Task :plus:test
 35.2sec, org.apache.calcite.adapter.tpch.TpchTest 
> testQuery11()
 16.3sec, org.apache.calcite.adapter.tpch.TpchTest 
> testQuery16()
 11.9sec, org.apache.calcite.adapter.tpch.TpchTest 
> testQuery22()
 36.3sec, org.apache.calcite.adapter.tpch.TpchTest 
> testQuery06()
 17.7sec, org.apache.calcite.adapter.tpch.TpchTest 
> testQuery14()
 36.8sec, org.apache.calcite.adapter.tpch.TpchTest 
> testQuery01()
 36.9sec, org.apache.calcite.adapter.tpch.TpchTest 
> testQuery04()
 15.2sec, org.apache.calcite.adapter.tpch.TpchTest 
> testQuery20()
 36.9sec, org.apache.calcite.adapter.tpch.TpchTest 
> testQuery12()
 17.9sec, org.apache.calcite.adapter.tpch.TpchTest 
> testQuery15()
 37.2sec, org.apache.calcite.adapter.tpch.TpchTest 
> testQuery03()
 37.3sec, org.apache.calcite.adapter.tpch.TpchTest 
> testQuery08()
 18.9sec, org.apache.calcite.adapter.tpch.TpchTest 
> testQuery13()
 37.3sec, org.apache.calcite.adapter.tpch.TpchTest 
> testQuery10()
 37.4sec, org.apache.calcite.adapter.tpch.TpchTest 
> testQuery09()
 17.6sec, org.apache.calcite.adapter.tpch.TpchTest 
> testQuery18()
 18.2sec, org.apache.calcite.adapter.tpch.TpchTest 
> testQuery17()
 38.5sec, org.apache.calcite.adapter.tpch.TpchTest 
> testQuery02Conversion()
 38.7sec, org.apache.calcite.adapter.tpch.TpchTest 
> testQuery02()
 18.3sec, org.apache.calcite.adapter.tpch.TpchTest 
> testQuery21()
 47.4sec, org.apache.calcite.adapter.tpch.TpchTest 
> testQuery05()

> Task :geode:test
  4.1sec, 
org.apache.calcite.adapter.geode.rel.GeodeBookstoreTest > 
testSqlDistinctSort()
  4.2sec, 
org.apache.calcite.adapter.geode.rel.GeodeAllDataTypesTest > 
testSqlBooleanColumnNotFilter()
  4.2sec, 
org.apache.calcite.adapter.geode.rel.GeodeAllDataTypesTest > 

[jira] [Created] (CALCITE-6078) Explicit cast to DECIMAL types do not check for overflow

[Mihai Budiu (Jira)]

Mihai Budiu created CALCITE-6078:


 Summary: Explicit cast to DECIMAL types do not check for overflow
 Key: CALCITE-6078
 URL: https://issues.apache.org/jira/browse/CALCITE-6078
 Project: Calcite
  Issue Type: Bug
  Components: core
Affects Versions: 1.35.0
Reporter: Mihai Budiu


This is a follow-up from [CALCITE-5990]
That issue dealt with integers and floating point.
This issue is about casts to DECIMAL in which the cast value exceeds the scale 
of the target result. Apparently Calcite does not handle such casts properly. 
There are multiple disabled SqlOperatorTests for this condition.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [DISCUSS] State of the project 2023

[Ran Tao]

Really, totally agree with Mihai & Hongyu about documentation.

In fact, I have a similar problem.
The learning curve of calcite is indeed steep,  most of my learning comes
from source code.

Fortunately, we still have a relatively rich javadoc in the source code.
If there is no javadoc, I mostly rely on experience to guess a certain
field or a certain logic.
There are relatively few people around me who know about calcite.

Of course, now I try to ask questions on the mailing list,
but considering the asynchronous situation of the mailing list and the fact
that new-beginners may not be willing or comfortable to ask questions by
email, it may not always work.

If we have some documentation from simple to in-depth,
such as how to build a simple function, a rule, from parser to optimizer,
how to combine some basic components to complete the optimization of a
large SQL or even run it.
Slowly increase the depth so that it will be more friendly to new-beginners.

I can’t imagine that all new people would go directly to the source code to
see it.
There is still a certain threshold for this.
I hope that in the future we can have some documents that are progressive
from shallow to deep,
no matter what page or form they are provided.

hope the community will get better and better in the new year.


Best Regards,
Ran Tao
https://github.com/chucheng92


Hongyu Guo  于2023年10月27日周五 00:05写道：

> Hi devs,
>
> There is no doubt that Calcite boasts powerful capabilities, but the curve
> of acquiring and learning calcite is quite steep. After studying Calcite
> for a year, I have only gained a limited understanding of some of its
> modules. Mihai is about to contribute several documents related to calcite,
> which is truly exciting. Calcite is a treasure, and I hope there will be
> more developer documentation next year to enable developers to quickly
> grasp how to use calcite and how it works.
>
> Secondly, Calcite supports a wide array of SQL syntax, but there are still
> a few syntaxes that it does not cover. I hope that Calcite can be equipped
> with more comprehensive SQL syntax parsing capabilities, which will be the
> selling point that convinces more developers to opt for Calcite. I am
> anticipating that Calcite will support more syntax next year, both standard
> and non-standard, and I will continue to contribute in this direction.
>
> Best,
> Hongyu Guo
>
> On Tue, Oct 24, 2023 at 3:16 AM  wrote:
>
> > Hello all,
> >
> > Calcite is great! However, I think that there are several areas where the
> > project could do better:
> > - testing
> > - documentation
> > - legacy code cleanup
> >
> > (1) Testing: Most of my work in Calcite so far has been about testing. I
> > have contributed the SqlLogicTest suite, which uncovers many bugs.
> However,
> > I have not filed issues for any of these bugs, and I have not fixed any
> of
> > these bugs either, since I have been very busy with other bugs I found
> > using other testing methods.  I also have written a new test fixture used
> > for SqlOperatorTest tests, which finds lots of bugs, but I haven't sent a
> > PR for this one since there are too many failures. I was hoping other
> > people would be looking at the SLT bugs. (One other test fixture I
> proposed
> > was merged, though, and I hope it will prevent quite a few bugs too:
> > https://github.com/apache/calcite/pull/3433).
> >
> > I think testing could be improved a lot by getting Calcite to run more
> > tests from other open-source projects (e.g., Postgres, or MySql). For
> > example, it would be great to have a script to convert Postgres regress
> > tests
> >
> https://github.com/postgres/postgres/tree/master/src/test/regress/expectedto
> > to Quidem tests. These could be slow tests.
> >
> > (2) Documentation; Calcite has a steep learning curve. I think that
> better
> > documentation could help attract more developers and users. I would like
> to
> > propose adding a blog to the Calcite project web page. If every committer
> > writes two blog posts per year about some Calcite technical aspect, then
> > the project can quickly accumulate a lot of helpful information. The dev
> > mailing list does not seem to be well indexed by search engines; we could
> > even take some answers for questions on the mailing list and turn them
> into
> > short articles. I have written a blog post about several Calcite IRs,
> which
> > I plan to post in the following days on our company website (I will
> > actually send a request for review on this list when I do), but it would
> be
> > great to cross-post such documents on the Calcite project blog.
> >
> > (3) While poking around I have found examples of data structure that are
> > probably confusing. Some of them have been known to be confusing for a
> long
> > time: e,g: RexLiteral.typeName.
> >
> https://github.com/apache/calcite/blob/c83ac69111fd9e75af5e3615af29a72284667a4a/core/src/main/java/org/apache/calcite/rex/RexLiteral.java#L214
> > A comment from 2006 indicates that 

Removing FLOAT

[Mihai Budiu]

Hello,

It turns out that there is a lot of confusion in Calcite about what FLOAT is.
I have filed an issue about it: 
https://issues.apache.org/jira/browse/CALCITE-6074

It seems that the intent is for FLOAT to be an exact alias of DOUBLE.
If that's the case, we can remove a lot of code and prevent further confusions 
by just removing FLOAT as a SqlTypeName and using DOUBLE everywhere starting in 
the parser. The situation is very similar with DECIMAL and NUMERIC.

This will also prevent a lot of bugs in third party code that uses Calcite, 
since they cannot misinterpret what FLOAT is.

If you agree that this is the right thing, I will submit a PR which marks FLOAT 
as @Deprecated and removes all its uses in the codebase.

Mihai

Re: [ANNOUNCE] New committer: Mihai Budiu

[Julian Hyde]

Welcome, Mihai. Thank you for the excellent work that you have already done, 
and discussions you have started about how we can become better. 


> On Oct 26, 2023, at 8:33 AM, Tanner Clary  
> wrote:
> 
> Congrats, Mihai! You've definitely helped me along the way.
> 
> Best,
> Tanner
> 
> On Thu, Oct 26, 2023 at 7:40 AM Runkang He  wrote:
> 
>> Congratulations Mihai!
>> 
>> Best,
>> Runkang He
>> 
>> Zhe Hu  于2023年10月26日周四 21:40写道：
>> 
>>> Congrats, Mihai !
>>> 
>>> 
>>> Best
>>> ZheHu
>>> 
>>> 
>>>  Replied Message 
>>> | From | Bertil Chapuis |
>>> | Date | 10/26/2023 21:09 |
>>> | To |  |
>>> | Subject | Re: [ANNOUNCE] New committer: Mihai Budiu |
>>> Congratulations and welcome!
>>> 
>>> Bertil
>>> 
>>> On 26 Oct 2023, at 10:56, Stamatis Zampetakis  wrote:
>>> 
>>> Apache Calcite's Project Management Committee (PMC) has invited Mihai
>>> Budiu to become a committer, and we are pleased to announce that he
>>> has accepted.
>>> 
>>> Mihai has addressed numerous compile and runtime issues in SQL
>>> functions and has made several significant improvements to the test
>>> infrastructure to enhance code coverage, quality, and stability. In
>>> addition to code contributions, Mihai is highly active on the mailing
>>> list, where he answers questions, assists others, and shares ideas for
>>> future improvements. Mihai has also been writing blogs and giving
>>> talks about Calcite at various events and conferences, showcasing
>>> Calcite in both simple and more advanced use cases, which can greatly
>>> contribute to the growth of the community.
>>> 
>>> Mihai, 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: [DISCUSS] State of the project 2023

[Hongyu Guo]

Hi devs,

There is no doubt that Calcite boasts powerful capabilities, but the curve
of acquiring and learning calcite is quite steep. After studying Calcite
for a year, I have only gained a limited understanding of some of its
modules. Mihai is about to contribute several documents related to calcite,
which is truly exciting. Calcite is a treasure, and I hope there will be
more developer documentation next year to enable developers to quickly
grasp how to use calcite and how it works.

Secondly, Calcite supports a wide array of SQL syntax, but there are still
a few syntaxes that it does not cover. I hope that Calcite can be equipped
with more comprehensive SQL syntax parsing capabilities, which will be the
selling point that convinces more developers to opt for Calcite. I am
anticipating that Calcite will support more syntax next year, both standard
and non-standard, and I will continue to contribute in this direction.

Best,
Hongyu Guo

On Tue, Oct 24, 2023 at 3:16 AM  wrote:

> Hello all,
>
> Calcite is great! However, I think that there are several areas where the
> project could do better:
> - testing
> - documentation
> - legacy code cleanup
>
> (1) Testing: Most of my work in Calcite so far has been about testing. I
> have contributed the SqlLogicTest suite, which uncovers many bugs. However,
> I have not filed issues for any of these bugs, and I have not fixed any of
> these bugs either, since I have been very busy with other bugs I found
> using other testing methods.  I also have written a new test fixture used
> for SqlOperatorTest tests, which finds lots of bugs, but I haven't sent a
> PR for this one since there are too many failures. I was hoping other
> people would be looking at the SLT bugs. (One other test fixture I proposed
> was merged, though, and I hope it will prevent quite a few bugs too:
> https://github.com/apache/calcite/pull/3433).
>
> I think testing could be improved a lot by getting Calcite to run more
> tests from other open-source projects (e.g., Postgres, or MySql). For
> example, it would be great to have a script to convert Postgres regress
> tests
> https://github.com/postgres/postgres/tree/master/src/test/regress/expectedto
> to Quidem tests. These could be slow tests.
>
> (2) Documentation; Calcite has a steep learning curve. I think that better
> documentation could help attract more developers and users. I would like to
> propose adding a blog to the Calcite project web page. If every committer
> writes two blog posts per year about some Calcite technical aspect, then
> the project can quickly accumulate a lot of helpful information. The dev
> mailing list does not seem to be well indexed by search engines; we could
> even take some answers for questions on the mailing list and turn them into
> short articles. I have written a blog post about several Calcite IRs, which
> I plan to post in the following days on our company website (I will
> actually send a request for review on this list when I do), but it would be
> great to cross-post such documents on the Calcite project blog.
>
> (3) While poking around I have found examples of data structure that are
> probably confusing. Some of them have been known to be confusing for a long
> time: e,g: RexLiteral.typeName.
> https://github.com/apache/calcite/blob/c83ac69111fd9e75af5e3615af29a72284667a4a/core/src/main/java/org/apache/calcite/rex/RexLiteral.java#L214
> A comment from 2006 indicates that this field should not exist.
>
> Another example is https://github.com/apache/calcite/pull/3411, where I
> tried to fix up some problems with the type families. Such PRs are
> difficult to accept, in the short term they may increase the code entropy
> (like this one does, by creating deprecated functions and keeping the old
> ones too), and it is very hard to make sure that they don't break anything
> for users, and their value is questionable if people do not actually remove
> all uses that should be deprecated. This requires a sustained effort to
> cleanup; contributors could periodically self-assign a small cleanup task.
>
> Thank you,
> Mihai
>
> -Original Message-
> From: Stamatis Zampetakis
> Sent: Sunday, October 22, 2023 9:00 AM
> To: dev@calcite.apache.org
> Subject: [DISCUSS] State of the project 2023
>
> Hello community and happy birthday Calcite,
>
> Eight years ago (22 October 2015) Calcite graduated as a top-level Apache
> project [1]. At that point, the community decided to have an annual “state
> of the project” discussion, and we arrived at that time of the year.
>
> We have had three Calcite releases (1.33.0 to 1.35.0) so far in 2023 [2],
> with probably one more coming before the end of the year. With roughly 300
> commits coming in, it is evident that the community did a great job in
> fixing numerous bugs, landing new features, and bringing notable
> improvements and optimizations to the project. It is worth highlighting the
> collective effort that was done for improving the BigQuery dialect where

Re: [ANNOUNCE] New committer: Mihai Budiu

[Tanner Clary]

Congrats, Mihai! You've definitely helped me along the way.

Best,
Tanner

On Thu, Oct 26, 2023 at 7:40 AM Runkang He  wrote:

> Congratulations Mihai!
>
> Best,
> Runkang He
>
> Zhe Hu  于2023年10月26日周四 21:40写道：
>
> > Congrats, Mihai !
> >
> >
> > Best
> > ZheHu
> >
> >
> >  Replied Message 
> > | From | Bertil Chapuis |
> > | Date | 10/26/2023 21:09 |
> > | To |  |
> > | Subject | Re: [ANNOUNCE] New committer: Mihai Budiu |
> > Congratulations and welcome!
> >
> > Bertil
> >
> > On 26 Oct 2023, at 10:56, Stamatis Zampetakis  wrote:
> >
> > Apache Calcite's Project Management Committee (PMC) has invited Mihai
> > Budiu to become a committer, and we are pleased to announce that he
> > has accepted.
> >
> > Mihai has addressed numerous compile and runtime issues in SQL
> > functions and has made several significant improvements to the test
> > infrastructure to enhance code coverage, quality, and stability. In
> > addition to code contributions, Mihai is highly active on the mailing
> > list, where he answers questions, assists others, and shares ideas for
> > future improvements. Mihai has also been writing blogs and giving
> > talks about Calcite at various events and conferences, showcasing
> > Calcite in both simple and more advanced use cases, which can greatly
> > contribute to the growth of the community.
> >
> > Mihai, 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: How to handle a dynamic param as a set of values?

[Benedek Halasi]

Hey,

Firstly, thank you all for your help!

In the meantime, we found this stack overflow thread: [
https://stackoverflow.com/questions/178479/preparedstatement-in-clause-alternatives/10240302#10240302
]

The interesting part is the second example: `SELECT my_column FROM my_table
WHERE search_column IN (SELECT * FROM unnest(?))`

We tried it, and Calcite threw an `Illegal use of dynamic parameter`
exception, based on the source code, this was because Calcite doesn't infer
type information in this case.

We tried, and succeeded with: `SELECT my_column FROM my_table WHERE
search_column IN (SELECT * FROM unnest(cast(? as VARCHAR ARRAY)))`

Do I see correctly that this somewhat aligns with the idea of treating the
“external” array as a table?

The generated code that this query got translated to, seems to use
`EnumerableDefaults.semiJoin` to combine a full scan on `my_table` with the
values of the dynamic param.

Does anyone see any (potential) problem with this workaround?

Probably relevant, this is how we executed the query:
- use JDBC to connect to Calcite.
- call `connection#prepareStatement` with the said query.
- set the array on the prepared statement with
`preparedStatement.setArray(index, connection.createArrayOf(
SqlType.VARCHAR.name(), collection.toArray()));`

---

> BTW, do you know any databases that have the ability as you described?

We personally didn't try this yet, but based on the same Stack Overflow
thread, it seems like Postgres / JDBC 4 may support this use-case via `=
ANY(?)`

We tried (with Calcite) using `= ANY (?)` too, but behaved very similarly
to `IN (?)` which currently is an equivalent of `= ?`.

This isn't too surprising based on Postgres' docs (
https://www.postgresql.org/docs/current/functions-subquery.html#FUNCTIONS-SUBQUERY-ANY-SOME),
but still, might be interesting.

Thanks,
Ben










On Wed, 25 Oct 2023 at 22:18, Julian Hyde  wrote:

> I have wanted this feature in SQL APIs for thirty years.
>
> I call it the ‘join to array’ problem. If you have a collection of
> employee ids, the best you can do is the following:
>
>   void getEmployees(int[] empIds, Consumer nameConsumer) {
> PreparedStatement stmt =
>   connection.prepareStatement(“select ename from emp where empno = ?”);
> for (int empNo in empNos) {
>   stmt.setInt(1, empNo);
>   ResultSet r = stmt.executeQuery();
>   if (r.next()) {
> nameConsumer.accept(r.getString(1));
>   }
> }
>   }
>
> I always wanted to treat the “external” array as a table inside SQL:
>
>   PreparedStatmenet stmt =
> connection.prepareStatement(“select ename\n”
>   + "from emp cross join ? as empno\n”
>   + "where emp.empno = empno.value")
>
> This wish to join to arrays, and remove the boundary between SQL and
> programming language data structures, let me to create the Saffron language
> [1] and later Morel [2].
>
> I think it would be nice to add support in Calcite for bind variables
> whose values are arrays. Quite how that would look in SQL, and to the JDBC
> client, I don’t know.
>
> Julian
>
> [1]
> https://swarm.workshop.perforce.com/view/guest/julian_hyde/saffron/doc/overview.html
> [2]
> http://blog.hydromatic.net/2020/02/25/morel-a-functional-language-for-data.html
>
>
> > On Oct 25, 2023, at 4:26 AM, Ruben Q L  wrote:
> >
> > Benedek, AFAIK what you describe is simply not possible with Calcite
> > currently.
> >
> > Best,
> > Ruben
> >
> >
> > On Wed, Oct 25, 2023 at 12:22 PM Benchao Li 
> wrote:
> >
> >> Benedek,
> >>
> >> Per my understanding, dynamic parameters should be some placeholders
> >> of literals, which means that each dynamic parameter can only be a
> >> single literal. Hence, your requirement cannot be achieved by this
> >> definition.
> >>
> >> BTW, do you know any databases that have the ability as you described?
> >>
> >> Benedek Halasi  于2023年10月25日周三 19:12写道：
> >>>
> >>> Hi,
> >>>
> >>> We're looking for a way to parse and execute queries with Apache
> Calcite
> >>> that contain an `IN (?)` expression, where the dynamic parameter is a
> set
> >>> of values.
> >>>
> >>> As we've observed, Calcite handles dynamic parameters as single values,
> >> and
> >>> we haven't found a way to make it handle them differently. This causes
> >> some
> >>> transformations to be flawed (e.g., `IN (?)` gets transformed to `=
> ?`).
> >>>
> >>> Has anyone encountered this? Is there a go-to solution?
> >>>
> >>> Thanks in advance,
> >>> Ben
> >>
> >>
> >>
> >> --
> >>
> >> Best,
> >> Benchao Li
> >>
>
>

[jira] [Created] (CALCITE-6077) Add FACTORIAL functions (enabled in Hive and Spark library)

[Runkang He (Jira)]

Runkang He created CALCITE-6077:
---

 Summary: Add FACTORIAL functions (enabled in Hive and Spark 
library)
 Key: CALCITE-6077
 URL: https://issues.apache.org/jira/browse/CALCITE-6077
 Project: Calcite
  Issue Type: New Feature
  Components: core
Affects Versions: 1.35.0
Reporter: Runkang He


Add FACTORIAL functions (enabled in Hive and Spark library)
FACTORIAL(expr): Returns the factorial of expr. expr is [0..20]. Otherwise, 
returns NULL.
For example:

{code:sql}
SELECT factorial(5); 
>120
{code}

See more at 
[Hive|https://cwiki.apache.org/confluence/display/hive/languagemanual+udf#LanguageManualUDF-MathematicalFunctions]
 and [Spark|https://spark.apache.org/docs/latest/api/sql/index.html#factorial] 
doc.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [ANNOUNCE] New committer: Mihai Budiu

[Runkang He]

Congratulations Mihai!

Best,
Runkang He

Zhe Hu  于2023年10月26日周四 21:40写道：

> Congrats, Mihai !
>
>
> Best
> ZheHu
>
>
>  Replied Message 
> | From | Bertil Chapuis |
> | Date | 10/26/2023 21:09 |
> | To |  |
> | Subject | Re: [ANNOUNCE] New committer: Mihai Budiu |
> Congratulations and welcome!
>
> Bertil
>
> On 26 Oct 2023, at 10:56, Stamatis Zampetakis  wrote:
>
> Apache Calcite's Project Management Committee (PMC) has invited Mihai
> Budiu to become a committer, and we are pleased to announce that he
> has accepted.
>
> Mihai has addressed numerous compile and runtime issues in SQL
> functions and has made several significant improvements to the test
> infrastructure to enhance code coverage, quality, and stability. In
> addition to code contributions, Mihai is highly active on the mailing
> list, where he answers questions, assists others, and shares ideas for
> future improvements. Mihai has also been writing blogs and giving
> talks about Calcite at various events and conferences, showcasing
> Calcite in both simple and more advanced use cases, which can greatly
> contribute to the growth of the community.
>
> Mihai, 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: [ANNOUNCE] New committer: Mihai Budiu

[Zhe Hu]

Congrats, Mihai !


Best
ZheHu


 Replied Message 
| From | Bertil Chapuis |
| Date | 10/26/2023 21:09 |
| To |  |
| Subject | Re: [ANNOUNCE] New committer: Mihai Budiu |
Congratulations and welcome!

Bertil

On 26 Oct 2023, at 10:56, Stamatis Zampetakis  wrote:

Apache Calcite's Project Management Committee (PMC) has invited Mihai
Budiu to become a committer, and we are pleased to announce that he
has accepted.

Mihai has addressed numerous compile and runtime issues in SQL
functions and has made several significant improvements to the test
infrastructure to enhance code coverage, quality, and stability. In
addition to code contributions, Mihai is highly active on the mailing
list, where he answers questions, assists others, and shares ideas for
future improvements. Mihai has also been writing blogs and giving
talks about Calcite at various events and conferences, showcasing
Calcite in both simple and more advanced use cases, which can greatly
contribute to the growth of the community.

Mihai, 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: [ANNOUNCE] New committer: Mihai Budiu

[Bertil Chapuis]

Congratulations and welcome!

Bertil

> On 26 Oct 2023, at 10:56, Stamatis Zampetakis  wrote:
> 
> Apache Calcite's Project Management Committee (PMC) has invited Mihai
> Budiu to become a committer, and we are pleased to announce that he
> has accepted.
> 
> Mihai has addressed numerous compile and runtime issues in SQL
> functions and has made several significant improvements to the test
> infrastructure to enhance code coverage, quality, and stability. In
> addition to code contributions, Mihai is highly active on the mailing
> list, where he answers questions, assists others, and shares ideas for
> future improvements. Mihai has also been writing blogs and giving
> talks about Calcite at various events and conferences, showcasing
> Calcite in both simple and more advanced use cases, which can greatly
> contribute to the growth of the community.
> 
> Mihai, 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



signature.asc
Description: Message signed with OpenPGP

Re: [ANNOUNCE] New committer: Mihai Budiu

[Jiajun Xie]

Congratulations Mihai!
Well deserved!

On Thu, 26 Oct 2023 at 20:08, Ran Tao  wrote:

> Congratulations, Mihai !
> and thanks for the review in the issue and PR !
>
> Best Regards,
> Ran Tao
>
> Stamatis Zampetakis  于2023年10月26日周四 16:57写道：
>
> > Apache Calcite's Project Management Committee (PMC) has invited Mihai
> > Budiu to become a committer, and we are pleased to announce that he
> > has accepted.
> >
> > Mihai has addressed numerous compile and runtime issues in SQL
> > functions and has made several significant improvements to the test
> > infrastructure to enhance code coverage, quality, and stability. In
> > addition to code contributions, Mihai is highly active on the mailing
> > list, where he answers questions, assists others, and shares ideas for
> > future improvements. Mihai has also been writing blogs and giving
> > talks about Calcite at various events and conferences, showcasing
> > Calcite in both simple and more advanced use cases, which can greatly
> > contribute to the growth of the community.
> >
> > Mihai, 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: [ANNOUNCE] New committer: Mihai Budiu

[Andrei Sereda]

Congratulations, Mihai!

On Thu, Oct 26, 2023 at 08:08 Ran Tao  wrote:

> Congratulations, Mihai !
> and thanks for the review in the issue and PR !
>
> Best Regards,
> Ran Tao
>
> Stamatis Zampetakis  于2023年10月26日周四 16:57写道：
>
> > Apache Calcite's Project Management Committee (PMC) has invited Mihai
> > Budiu to become a committer, and we are pleased to announce that he
> > has accepted.
> >
> > Mihai has addressed numerous compile and runtime issues in SQL
> > functions and has made several significant improvements to the test
> > infrastructure to enhance code coverage, quality, and stability. In
> > addition to code contributions, Mihai is highly active on the mailing
> > list, where he answers questions, assists others, and shares ideas for
> > future improvements. Mihai has also been writing blogs and giving
> > talks about Calcite at various events and conferences, showcasing
> > Calcite in both simple and more advanced use cases, which can greatly
> > contribute to the growth of the community.
> >
> > Mihai, 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: [ANNOUNCE] New committer: Mihai Budiu

[Ran Tao]

Congratulations, Mihai !
and thanks for the review in the issue and PR !

Best Regards,
Ran Tao

Stamatis Zampetakis  于2023年10月26日周四 16:57写道：

> Apache Calcite's Project Management Committee (PMC) has invited Mihai
> Budiu to become a committer, and we are pleased to announce that he
> has accepted.
>
> Mihai has addressed numerous compile and runtime issues in SQL
> functions and has made several significant improvements to the test
> infrastructure to enhance code coverage, quality, and stability. In
> addition to code contributions, Mihai is highly active on the mailing
> list, where he answers questions, assists others, and shares ideas for
> future improvements. Mihai has also been writing blogs and giving
> talks about Calcite at various events and conferences, showcasing
> Calcite in both simple and more advanced use cases, which can greatly
> contribute to the growth of the community.
>
> Mihai, 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
>

[jira] [Created] (CALCITE-6076) Table function can not refer other table columns

[hongyu guo (Jira)]

hongyu guo created CALCITE-6076:
---

 Summary: Table function can not refer other table columns
 Key: CALCITE-6076
 URL: https://issues.apache.org/jira/browse/CALCITE-6076
 Project: Calcite
  Issue Type: Bug
  Components: core
Affects Versions: 1.35.0
Reporter: hongyu guo


SQL:
{code:java}
select rmp.i from emp, table(ramp(emp.deptno)) as rmp {code}
will throw an error:
{code:java}
Table 'EMP' not found {code}
during the validation. 

this SQL fails because the scope of the table function during the verification 
is CatalogScope, not JoinScope.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [ANNOUNCE] New committer: Mihai Budiu

[Dan Zou]

Congratulations, Mihai!

Best,
Dan Zou   





> 2023年10月26日 19:19，Sergey Nuyanzin  写道：
> 
> Congratulations

Re: [ANNOUNCE] New committer: Mihai Budiu

[Hongyu Guo]

Congratulations!

On Thu, Oct 26, 2023 at 7:20 PM Sergey Nuyanzin  wrote:

> Congratulations Mihai!
>
> On Thu, Oct 26, 2023 at 1:15 PM LakeShen 
> wrote:
>
> > Congratulations Mihai.
> >
> > Best,
> > LakeShen
> >
> > Alessandro Solimando  于2023年10月26日周四
> > 17:55写道：
> >
> > > Congratulations Mihai, very well deserved!
> > >
> > > On Thu, 26 Oct 2023 at 11:46, Ruben Q L  wrote:
> > >
> > > > Congratulations! Welcome on board!
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, Oct 26, 2023 at 10:37 AM Benchao Li 
> > > wrote:
> > > >
> > > > > Congrats, Mihai! Well deserved!
> > > > >
> > > > > Francis Chuang  于2023年10月26日周四 16:59写道：
> > > > > >
> > > > > > Congrats, Mihai!
> > > > > >
> > > > > > On 26/10/2023 7:56 pm, Stamatis Zampetakis wrote:
> > > > > > > Apache Calcite's Project Management Committee (PMC) has invited
> > > Mihai
> > > > > > > Budiu to become a committer, and we are pleased to announce
> that
> > he
> > > > > > > has accepted.
> > > > > > >
> > > > > > > Mihai has addressed numerous compile and runtime issues in SQL
> > > > > > > functions and has made several significant improvements to the
> > test
> > > > > > > infrastructure to enhance code coverage, quality, and
> stability.
> > In
> > > > > > > addition to code contributions, Mihai is highly active on the
> > > mailing
> > > > > > > list, where he answers questions, assists others, and shares
> > ideas
> > > > for
> > > > > > > future improvements. Mihai has also been writing blogs and
> giving
> > > > > > > talks about Calcite at various events and conferences,
> showcasing
> > > > > > > Calcite in both simple and more advanced use cases, which can
> > > greatly
> > > > > > > contribute to the growth of the community.
> > > > > > >
> > > > > > > Mihai, 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
> > > > >
> > > >
> > >
> >
>
>
> --
> Best regards,
> Sergey
>

Re: [ANNOUNCE] New committer: Mihai Budiu

[Sergey Nuyanzin]

Congratulations Mihai!

On Thu, Oct 26, 2023 at 1:15 PM LakeShen  wrote:

> Congratulations Mihai.
>
> Best,
> LakeShen
>
> Alessandro Solimando  于2023年10月26日周四
> 17:55写道：
>
> > Congratulations Mihai, very well deserved!
> >
> > On Thu, 26 Oct 2023 at 11:46, Ruben Q L  wrote:
> >
> > > Congratulations! Welcome on board!
> > >
> > >
> > >
> > >
> > > On Thu, Oct 26, 2023 at 10:37 AM Benchao Li 
> > wrote:
> > >
> > > > Congrats, Mihai! Well deserved!
> > > >
> > > > Francis Chuang  于2023年10月26日周四 16:59写道：
> > > > >
> > > > > Congrats, Mihai!
> > > > >
> > > > > On 26/10/2023 7:56 pm, Stamatis Zampetakis wrote:
> > > > > > Apache Calcite's Project Management Committee (PMC) has invited
> > Mihai
> > > > > > Budiu to become a committer, and we are pleased to announce that
> he
> > > > > > has accepted.
> > > > > >
> > > > > > Mihai has addressed numerous compile and runtime issues in SQL
> > > > > > functions and has made several significant improvements to the
> test
> > > > > > infrastructure to enhance code coverage, quality, and stability.
> In
> > > > > > addition to code contributions, Mihai is highly active on the
> > mailing
> > > > > > list, where he answers questions, assists others, and shares
> ideas
> > > for
> > > > > > future improvements. Mihai has also been writing blogs and giving
> > > > > > talks about Calcite at various events and conferences, showcasing
> > > > > > Calcite in both simple and more advanced use cases, which can
> > greatly
> > > > > > contribute to the growth of the community.
> > > > > >
> > > > > > Mihai, 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
> > > >
> > >
> >
>


-- 
Best regards,
Sergey

Re: [ANNOUNCE] New committer: Mihai Budiu

[LakeShen]

Congratulations Mihai.

Best,
LakeShen

Alessandro Solimando  于2023年10月26日周四
17:55写道：

> Congratulations Mihai, very well deserved!
>
> On Thu, 26 Oct 2023 at 11:46, Ruben Q L  wrote:
>
> > Congratulations! Welcome on board!
> >
> >
> >
> >
> > On Thu, Oct 26, 2023 at 10:37 AM Benchao Li 
> wrote:
> >
> > > Congrats, Mihai! Well deserved!
> > >
> > > Francis Chuang  于2023年10月26日周四 16:59写道：
> > > >
> > > > Congrats, Mihai!
> > > >
> > > > On 26/10/2023 7:56 pm, Stamatis Zampetakis wrote:
> > > > > Apache Calcite's Project Management Committee (PMC) has invited
> Mihai
> > > > > Budiu to become a committer, and we are pleased to announce that he
> > > > > has accepted.
> > > > >
> > > > > Mihai has addressed numerous compile and runtime issues in SQL
> > > > > functions and has made several significant improvements to the test
> > > > > infrastructure to enhance code coverage, quality, and stability. In
> > > > > addition to code contributions, Mihai is highly active on the
> mailing
> > > > > list, where he answers questions, assists others, and shares ideas
> > for
> > > > > future improvements. Mihai has also been writing blogs and giving
> > > > > talks about Calcite at various events and conferences, showcasing
> > > > > Calcite in both simple and more advanced use cases, which can
> greatly
> > > > > contribute to the growth of the community.
> > > > >
> > > > > Mihai, 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: Mihai Budiu

[Alessandro Solimando]

Congratulations Mihai, very well deserved!

On Thu, 26 Oct 2023 at 11:46, Ruben Q L  wrote:

> Congratulations! Welcome on board!
>
>
>
>
> On Thu, Oct 26, 2023 at 10:37 AM Benchao Li  wrote:
>
> > Congrats, Mihai! Well deserved!
> >
> > Francis Chuang  于2023年10月26日周四 16:59写道：
> > >
> > > Congrats, Mihai!
> > >
> > > On 26/10/2023 7:56 pm, Stamatis Zampetakis wrote:
> > > > Apache Calcite's Project Management Committee (PMC) has invited Mihai
> > > > Budiu to become a committer, and we are pleased to announce that he
> > > > has accepted.
> > > >
> > > > Mihai has addressed numerous compile and runtime issues in SQL
> > > > functions and has made several significant improvements to the test
> > > > infrastructure to enhance code coverage, quality, and stability. In
> > > > addition to code contributions, Mihai is highly active on the mailing
> > > > list, where he answers questions, assists others, and shares ideas
> for
> > > > future improvements. Mihai has also been writing blogs and giving
> > > > talks about Calcite at various events and conferences, showcasing
> > > > Calcite in both simple and more advanced use cases, which can greatly
> > > > contribute to the growth of the community.
> > > >
> > > > Mihai, 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: Mihai Budiu

[Ruben Q L]

Congratulations! Welcome on board!




On Thu, Oct 26, 2023 at 10:37 AM Benchao Li  wrote:

> Congrats, Mihai! Well deserved!
>
> Francis Chuang  于2023年10月26日周四 16:59写道：
> >
> > Congrats, Mihai!
> >
> > On 26/10/2023 7:56 pm, Stamatis Zampetakis wrote:
> > > Apache Calcite's Project Management Committee (PMC) has invited Mihai
> > > Budiu to become a committer, and we are pleased to announce that he
> > > has accepted.
> > >
> > > Mihai has addressed numerous compile and runtime issues in SQL
> > > functions and has made several significant improvements to the test
> > > infrastructure to enhance code coverage, quality, and stability. In
> > > addition to code contributions, Mihai is highly active on the mailing
> > > list, where he answers questions, assists others, and shares ideas for
> > > future improvements. Mihai has also been writing blogs and giving
> > > talks about Calcite at various events and conferences, showcasing
> > > Calcite in both simple and more advanced use cases, which can greatly
> > > contribute to the growth of the community.
> > >
> > > Mihai, 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: Mihai Budiu

[Benchao Li]

Congrats, Mihai! Well deserved!

Francis Chuang  于2023年10月26日周四 16:59写道：
>
> Congrats, Mihai!
>
> On 26/10/2023 7:56 pm, Stamatis Zampetakis wrote:
> > Apache Calcite's Project Management Committee (PMC) has invited Mihai
> > Budiu to become a committer, and we are pleased to announce that he
> > has accepted.
> >
> > Mihai has addressed numerous compile and runtime issues in SQL
> > functions and has made several significant improvements to the test
> > infrastructure to enhance code coverage, quality, and stability. In
> > addition to code contributions, Mihai is highly active on the mailing
> > list, where he answers questions, assists others, and shares ideas for
> > future improvements. Mihai has also been writing blogs and giving
> > talks about Calcite at various events and conferences, showcasing
> > Calcite in both simple and more advanced use cases, which can greatly
> > contribute to the growth of the community.
> >
> > Mihai, 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: Mihai Budiu

[Francis Chuang]

Congrats, Mihai!

On 26/10/2023 7:56 pm, Stamatis Zampetakis wrote:

Apache Calcite's Project Management Committee (PMC) has invited Mihai
Budiu to become a committer, and we are pleased to announce that he
has accepted.

Mihai has addressed numerous compile and runtime issues in SQL
functions and has made several significant improvements to the test
infrastructure to enhance code coverage, quality, and stability. In
addition to code contributions, Mihai is highly active on the mailing
list, where he answers questions, assists others, and shares ideas for
future improvements. Mihai has also been writing blogs and giving
talks about Calcite at various events and conferences, showcasing
Calcite in both simple and more advanced use cases, which can greatly
contribute to the growth of the community.

Mihai, 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

[ANNOUNCE] New committer: Mihai Budiu

[Stamatis Zampetakis]

Apache Calcite's Project Management Committee (PMC) has invited Mihai
Budiu to become a committer, and we are pleased to announce that he
has accepted.

Mihai has addressed numerous compile and runtime issues in SQL
functions and has made several significant improvements to the test
infrastructure to enhance code coverage, quality, and stability. In
addition to code contributions, Mihai is highly active on the mailing
list, where he answers questions, assists others, and shares ideas for
future improvements. Mihai has also been writing blogs and giving
talks about Calcite at various events and conferences, showcasing
Calcite in both simple and more advanced use cases, which can greatly
contribute to the growth of the community.

Mihai, 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

[jira] [Created] (CALCITE-6075) There is a problem with the git clone address link

[Jira]

蔡灿材 created CALCITE-6075:


 Summary: There is a problem with the git clone address link
 Key: CALCITE-6075
 URL: https://issues.apache.org/jira/browse/CALCITE-6075
 Project: Calcite
  Issue Type: Improvement
  Components: site
Affects Versions: 1.35.0
Reporter: 蔡灿材
 Fix For: 1.35.0
 Attachments: 2023-10-26 16-28-15屏幕截图.png

git clone 
git://github.com/apache/calcite.git并没有这种写法，应该是https://github.com/apache/calcite.git或者g...@github.com:apache/calcite.git



--
This message was sent by Atlassian Jira
(v8.20.10#820010)