[jira] [Created] (CALCITE-7108) Upgrade aggdesigner-algorithm from 6.0 to 6.1

Julian Hyde created CALCITE-7108: Summary: Upgrade aggdesigner-algorithm from 6.0 to 6.1 Key: CALCITE-7108 URL: https://issues.apache.org/jira/browse/CALCITE-7108 Project: Calcite Issue Type

Re: An issue on calcite-1.38.0 searching for help

You seem to be operating under some rather bizarre constraints that I don’t fully understand. I would use done column aliases so that columns of different types have different names. I would also introduce some casts. Can you give a query that reproduces the problem outside of your environment?

Re: Reduce class loading during query optimizing

Mihai has explained well why we use the “big hammer” of the executor. As a compiler, you can’t afford to take shortcuts on semantics. It makes sense to use the “real” executor when doing constant reduction, and the price we pay is increased compilation latency. The “real” executor is a compiler

Re: [DISCUSS] Preserving Output Alias Names After RelNode Optimization

Irresistible force meets immovable object. A lot of people want nice, predictable names; but I and others have explained at length why it is fundamentally very hard to do. It’s hard to even specify what is the right thing. The Volcano planning algorithm is subtle and powerful, and the corner ca

Re: [DISCUSS] Preserving Output Alias Names After RelNode Optimization

ven be achieved for the decorrelator itself. > > Mihai > > > > From: Julian Hyde > Sent: Wednesday, June 25, 2025 7:59 AM > To: dev@calcite.apache.org > Subject: Re: [DISCUSS] Preserving Output Alias Names After RelNode > Optimization > >

Re: [DISCUSS] Preserving Output Alias Names After RelNode Optimization

Preserving column names through the optimization process, and many rewrite rules being applied, is very hard if not impossible. Instead I would approach this as the RelToSqlConverter does, and try to produce the best/most concise/most human-readable SQL possible given a RelRoot. Flattening the

Re: [DISCUSS] Some questions related to subquery issues

I added some remarks to the jira. I am worried that UUIDs will make planning non-repeatable. Currently if you make equivalent plans via different sequences of rule-firings they will be identical. That is really important to Calcite’s ability to “reason locally”. I would spend more effort fixi

Re: release script failed

Maven Central is more definitive than MvnRepository. I see 1.40 artifacts have correctly deployed to Central. https://central.sonatype.com/artifact/org.apache.calcite/calcite-core/versions On Wed, May 28, 2025 at 8:53 AM Alessandro Solimando wrote: > > Hello, > the release plugin failed with a 5

Re: [DISCUSS] Pipe syntax

er specifically > for pipeline syntax from scratch. > > If no one takes over this work, I can start this work in the second half of > the year, because the first half of the year is too busy. > > Best wishes, > Cancai Cai > > On 2025/05/19 17:49:20 Julian Hyd

Re: [DISCUSS] Jira first

. It's not easy to have a dialogue that alternates between > the two sites - no causality is maintained. > > A third problem is that we have lots of contributors for whom English is a > second language (I am one of them), and sometimes the code is easier to read > than the s

[DISCUSS] Jira first

Calcite has always been a "Jira first" project, where all significant commits have a Jira case number (CALCITE-). We've not allowed patch attachments since the very early days, so each of those commits also has a GitHub pull request (PR). Given that discussion can occur on the Jira case and th

Re: [ANNOUNCE] New committer: Zhen Chen

Thanks for your contributions, and welcome! Julian > On May 19, 2025, at 2:33 PM, Francis Chuang wrote: > > Congratulations! > > On 20/05/2025 6:31 am, Mihai Budiu wrote: >> Apache Calcite's Project Management Committee (PMC) has invited Zhen Chen to >> become a committer, and we are pleased

[DISCUSS] Pipe syntax

SQL pipe syntax was introduced as part of GoogleSQL and is described in a paper "SQL Has Problems. We Can Fix Them: Pipe Syntax In SQL" by Jeff Shute and others[1]. Other vendors, including Firebolt and Databricks, have announced support. I have logged a Jira case to support pipe syntax in Calcite[

[jira] [Created] (CALCITE-7028) Implement SQL pipe syntax

Julian Hyde created CALCITE-7028: Summary: Implement SQL pipe syntax Key: CALCITE-7028 URL: https://issues.apache.org/jira/browse/CALCITE-7028 Project: Calcite Issue Type: Bug

Re: Why are JOIN/correlation predicates not pushed down as IN lists across JDBC datasources?

The short answer to your “why?” is that no one ever did the work to make this happen. The work would be a planner rule plus a cost model. But please remember that there is usually no good plan for a federated join. There are a few algorithms (e.g. using bloom filters) that may help a little,

Re: [DISCUSS] （CALCITE-6944）Cannot parse parenthesized partition by in Table Function

I agree with Mihai, but in some cases there are several correct representations. For example, the expression “x + y * z” can be represented as “x + y * z”, “x + (y * z)” and “(x + (y * z))”. All are valid representations, and the unparser has a mode where it will generate the last one, with lots

[DISCUSS] Can logical operators have physical properties?

CALCITE-6925 surfaced an interesting question - should logical operators have physical properties (such as sorting and distribution)? I don’t know the answer. I got some things wrong when I created Calcite, and “What is a logical operator?” is a question I never fully answered. If you’re intere

Re: [ANNOUNCE] Xiong Duan joins Calcite PMC

Thanks for your many contributions to Calcite. This is well-earned. On Mar 29, 2025, at 1:32 AM, Alessandro Solimando wrote: > > Congratulations, > very well deserved! > >> On Sat, Mar 29, 2025, 09:03 Francis Chuang wrote: >> >> Congratulations! >> >>> On 29/03/2025 6:31 pm, Stamatis Zamp

Re: Parsing expression inside RelShuttle

sion: > * FROM sensitive_table -- > But that will luckily not give her access to sensitive_table since we're > only extracting the first RexNode and not the resulting TableScan. But > perhaps there are other tricks I'm not considering? > > This is a good starting point,

Re: Is it possible to have type system with scale that is precision agnostic?

Postgres’ numeric and decimal types store arbitrary numbers of digits (left and right of the point). We could implement something similar in Calcite (a reasonable implementation would convert the decimal values to strings like “123.45” and “-.0678”, and numeric values to strings in another base)

Re: [DISCUSSION] Notes on some database versions

I agree that this is a problem. Assuming that a database dialect improves over time, if someone is connecting to version 5 of a database, they would like Calcite to generate the best SQL for version 5, but not use features that were added in version 6 or later. To minimize the amount of code, we

Re: Parsing expression inside RelShuttle

It seems that your requirement is for an ‘expression parser’ that works in the context of a table, and goes from SQL text via AST and validation to a RexNode. You can achieve this by generating a query, “select “ + expression + “ from “ + table, and sending it through the parse/validate/SQL-to-r

Re: Splitting multiconditional joins into binary joins?

Since these are inner joins, you could convert Join(i0, i1, c0 and c1 and c2) into Filter(c2) Filter(c1) Filter(c0) CrossJoin(i0, i1) without changing semantics. I believe that’s what LoptOptimizeMultiJoinRule does - it shreds the joins into a join graph and reassembles

Re: Splitting multiconditional joins into binary joins?

> On Mar 14, 2025, at 10:43 AM, Julian Hyde wrote: > > Since these are inner joins, you could convert > > Join(i0, i1, c0 and c1 and c2) > > into > > Filter(c2) >Filter(c1) > Filter(c0) >CrossJoin(i0, i1) > > without

Re: RelFieldTrimmer not optimally trimming after filters under joins?

Probably this should be done by RelFieldTrimmer, but it should be a mode (boolean flag). If it started adding a bunch of new Project operators it might break existing clients. Maybe even several modes. Some people might not to add Project under an Aggregate (because Aggregate implicitly project

Re: Questions Regarding Type Coercion and CAST Transformations in SqlValidator and RexBuilder

Some conversions are widening. For example, if I convert a SMALLINT to an INTEGER, there’s no possibility of data loss because every valid SMALLINT value has a corresponding INTEGER value. The existence of widening conversions means that means that we can get by with fewer functions and operato

Re: RelFieldTrimmer not optimally trimming after filters under joins?

passes > down to the Filter that it doesn't need that column. Filter does need it, > so it keeps, and returns a rowtype/mapping that includes the column. > Project doesn't need it, so it drops that field from the project > expression, and returns a rowtype/mapping that doesn

Re: RelFieldTrimmer not optimally trimming after filters under joins?

I don’t think I understand this conversation. RelFieldTrimmer is intended to be invoked on the whole tree. Each node, when invoking the trimmer on its input (child), tells the trimmer which of the fields of that input it actually uses. Now ‘which fields it actually uses’ is based on the fields t

Re: [DISCUSS] Towards Calcite 1.39.0

+1 for March 10th RC There are only 4 open issues tagged 1.39 [ https://issues.apache.org/jira/issues/?jql=project%20%3D%20CALCITE%20AND%20fixVersion%20%3D%201.39.0%20%20AND%20%20%20statusCategory%20%20!%3D%20Done ] > On Mar 4, 2025, at 2:56 AM, Alessandro Solimando > wrote: > > I share the

Re: Question about scale after parsing day/time intervals to RexLiteral

Sorry to be pedantic but it’s important. To me, ‘parse’ means to go from text to an AST, without applying judgments such as type system. As far as I can tell, there is no problem with ‘parsing’. The parser produces an AST, specifically a SqlLiteral, with all of the digits that were in the SQL te

Re: Broken website images due to Content Security Policy

It’s a shame. The avatars make the site better. And no one’s privacy is being violated. Julian > On Feb 17, 2025, at 05:40, Istvan Toth wrote: > > I prefer removing the avatars. > Having snapshots for existing ppl is half-solution, and trying to add some > kind of sync mechanism on build wo

Re: Fragmentation of dialect tests

Thank you, everyone, for your words of support. It means a lot to me, when I jump into a big refactoring, to know that people approve of the direction and are prepared to help. Step 1 is nearly complete: add a ‘done()’ call to each test in RelToSqlConverterTest so that it validates each stateme

Fragmentation of dialect tests

Calcite committers, We have too many dialect tests (RelToSqlConverterTest alone is 10,000 lines long) and we have too few (for many functions and operators, we test the translation to SQL in only one or two dialects, and we never actually execute that SQL). I have a suggestion that I think will m

[jira] [Created] (CALCITE-6837) Invalid code generated for ROW_NUMBER function in Enumerable convention

Julian Hyde created CALCITE-6837: Summary: Invalid code generated for ROW_NUMBER function in Enumerable convention Key: CALCITE-6837 URL: https://issues.apache.org/jira/browse/CALCITE-6837 Project

[jira] [Created] (CALCITE-6834) In query that applies COALESCE to nullable SUM, EnumerableProjectToCalcRule throws AssertionError

Julian Hyde created CALCITE-6834: Summary: In query that applies COALESCE to nullable SUM, EnumerableProjectToCalcRule throws AssertionError Key: CALCITE-6834 URL: https://issues.apache.org/jira/browse/CALCITE

[jira] [Created] (CALCITE-6833) JDBC adapter generates invalid table alias for semi-join in UNION

Julian Hyde created CALCITE-6833: Summary: JDBC adapter generates invalid table alias for semi-join in UNION Key: CALCITE-6833 URL: https://issues.apache.org/jira/browse/CALCITE-6833 Project: Calcite

[jira] [Created] (CALCITE-6824) FieldTrimmer corrupts plan if query compares two boolean subqueries

Julian Hyde created CALCITE-6824: Summary: FieldTrimmer corrupts plan if query compares two boolean subqueries Key: CALCITE-6824 URL: https://issues.apache.org/jira/browse/CALCITE-6824 Project

Re: [DISCUSS] Towards Avatica 1.26.0

;>>>>>>> >>>>>>>> On Fri, Oct 25, 2024 at 7:44 AM Istvan Toth >>>> wrote: >>>>>>>> >>>>>>>>> Re CALCITE-6590, I think we have agreed to go with the reflection >>>>>>>&g

Re: [ANNOUNCE] New committer: Cancai Cai

Cancai, you have earned this with your hard work, many contributions and reviews, and limitless enthusiasm and energy. We are delighted to have you in our project. Julian > On Jan 20, 2025, at 8:25 AM, suibianwanwan > wrote: > > Congratulations! > > > Best regards, > Suibianwanwan > >>

Re: [DISCUSS] Apache Calcite Meetup February 2025

S] Apache Calcite Meetup February 2025 > > I can also give a talk based on some recent work that we did in Apache > Hive around CTEs. > > With Walaa's and mine we now have five talks for the meetup. > > 1. Improving testing of JDBC adapter's dialects - Julian Hyde (

Re: Question: RelJson(Reader|Writer) purpose and test coverage

That there are open bugs doesn’t imply that RelJson isn’t used for serious purposes. Just that it’s open source software. Bugs get fixed only when someone cares enough to fix them. It is very useful to log bugs even if there is no guarantee that they will be immediately fixed. As a searchable i

Re: Tech blog post on Apache Calcite use-cases

Thanks for sharing, Wegdan! I shared on the Twitter account: https://x.com/ApacheCalcite/status/1876703745012064316 > On Jan 7, 2025, at 4:08 AM, Wegdan Ghazi > wrote: > > Hello, > > We've been using Calcite at Picnic for quite some > time now and it's enabled us to

Re: In clause having issues with string type

I see NVARCHAR, which is a Microsoft SQL Server variant of string that uses wide characters. I didn’t even know that Calcite supports NVARCHAR. But Calcite has always had problems correctly converting between CHAR and VARCHAR, and I expect NVARCHAR is similar. > On Jan 7, 2025, at 9:49 AM, Mih

Re: [DISCUSS] Apache Calcite Meetup February 2025

Excellent idea. I'm always happy to give a talk about Calcite, and could travel to Santa Clara in person. One possible topic is "Improving testing of our JDBC adapter's dialects". On Mon, Dec 23, 2024 at 9:46 AM Mihai Budiu wrote: > > Great idea, I would participate in person or in the hybrid for

Re: array comparisons

The ‘obvious’ semantics: Two array expressions are comparable iff their element types are comparable. They would compare equal iff they have the same length and all their elements are pairwise equal. If the validator doesn’t do that it is most likely because no one got around to it. If the SQL

Re: Meaning of date subtraction

1-03-01' - DATE '2020-01-01') MONTH AS m, >(DATE '2021-03-01' - DATE '2020-01-01') YEAR TO MONTH AS ym; ++-+---+ | Y | M | YM | ++-+---+ | +1 | +14 | +1-02 | ++-+---+ 1 row selected (0.02 seconds) > On Dec 10, 2024, at 9:04 PM, J

Re: Meaning of date subtraction

But the type of the value is different in each case, right? Julian > On Dec 10, 2024, at 20:11, Mihai Budiu wrote: > > What is the semantics of subtracting two dates (times, timestamps)? > The Calcite syntax is (d0 - d1) time_interval. > But the following programs evaluate to the same value: >

Re: literal "type" issues in my database

Also, there are more types than literal formats. For some types, e.g. TINYINT, the only way to create a literal is to use a cast: “CAST(3 AS TINYINT)”. This problem is not unique to SQL. In Java, if you want a literal of type short you write “(short) 3”. Julian > On Dec 10, 2024, at 6:11 AM,

[jira] [Created] (CALCITE-6716) WITH REPEATABLE (deterministic CTEs)

Julian Hyde created CALCITE-6716: Summary: WITH REPEATABLE (deterministic CTEs) Key: CALCITE-6716 URL: https://issues.apache.org/jira/browse/CALCITE-6716 Project: Calcite Issue Type: Bug

Re: Tackling Query Federation Use Case using Calcite

And Calcite has always done this. See a presentation I gave 12 years ago! https://www.slideshare.net/slideshow/optiq-a-sql-frontend-for-everything > On Dec 4, 2024, at 7:52 AM, Charles Givre wrote: > > Hi Aditya, > You might want to look at how Apache Drill does this. Drill uses Calcite fo

Re: Semantics of VARCHAR

Yes VARCHAR preserves trailing spaces. But your question is more about the semantics of CHAR. The literal is a CHAR(2). I think we should retain the trailing space in that string when we reinterpret it as a VARCHAR. But I’m not sure that we do. > On Dec 2, 2024, at 7:40 PM, Mihai Budiu wrote

Re: [DISCUSS] Calcite as SQL translator, and dialect testing

(including functionality that is closely related, like that cosine function), that refactorings have happened to allow future growth of the code, and refuse to merge PRs until that point is reached. > On Dec 2, 2024, at 12:13 PM, Julian Hyde wrote: > > In an open source project the core is

Re: [DISCUSS] Calcite as SQL translator, and dialect testing

s often because this is the JIRA > default, and people don't bother to change it. > > Mihai > > > From: Julian Hyde > Sent: Monday, December 2, 2024 11:40 AM > To: dev@calcite.apache.org > Subject: Re: [DISCUSS] Calcite as SQL transl

Re: Need Suggestion on Case expression simplification

I agree with Mihai, mostly. Yes it should be done as a RexNode-to-RexNode mapping. But hopefully it isn’t a dedicated class that subclasses RexVisitor and just deals with IS NOT TRUE. Each dialect should map calls to operators it does not support to operators that it does support. (I’ve not th

Re: [DISCUSS] Calcite as SQL translator, and dialect testing

t;\n" >>>> + "ORDER BY \"brand_name\""; >>>> final String sparkExpected = "SELECT *\n" >>>> + "FROM `foodmart`.`product`\n" >>>> + "ORDER BY `brand_name` NULLS LAST"; >>>> sq

Re: Checked arithmetic

ent is for it to be > used right after SqlToRel to "correct" plans that are intended for a dialect > that requires checked arithmetic. > > I will change the title everywhere in a bit, let's see if there are more > comments. > > Mihai > > _

Re: Checked arithmetic

indicating whether > checked arithmetic should be used or not. > > Thank you, > Mihai > > > From: Julian Hyde > Sent: Friday, October 4, 2024 12:20 PM > To: dev@calcite.apache.org > Subject: Re: Checked arithmetic > > > T

[DISCUSS] Calcite as SQL translator, and dialect testing

A recent case, https://issues.apache.org/jira/browse/CALCITE-6693, "Add Source SQL Dialect to RelToSqlConverterTest”, implies that people are using Calcite to translate SQL from dialect to another. The test wanted to test translating a SQL string from Presto to Redshift. I pushed back on that ca

Re: [DISCUSS] State of the project 2024

I feel that Calcite — the project and the community — are in good shape this year. There is a high velocity of contributions from a wide variety of people. Thank you to Benchao for steering the ship for the last twelve months. The rate at which contributors evolve into committers and then into P

Re: Parser error reporting

The Babel parser is a compromise. It tolerates ambiguity but occasionally accepts strings thst are invalid, and it makes the JavaCC engine work harder. I started a jira case and dev branch to upgrade JavaCC. I never completed it, but I recall that I solved many of the ambiguities in the grammar

Re: Discussion: Distinguish between casts for aligning null types and casts for other type conversion

A lot of us, myself included, are inclined to include nullability as part of the type. I realized that this is in part because we work with modern programming languages, where a nullable integer is literally a different type to an integer. (E.g. Option vs Integer.) But in the relational world,

Re: Calcite 1.38.0 still marked as unreleased in Jira

Ok, I've added the message. (In order to do this I had to reopen all issues and then close them again.) On Thu, Oct 17, 2024 at 8:45 AM Julian Hyde wrote: > > Thank you - but it doesn’t look like you added the message 'Resolved in > release 1.38.0 (2024-10-15)’ per the r

Re: Calcite 1.38.0 still marked as unreleased in Jira

Thank you - but it doesn’t look like you added the message 'Resolved in release 1.38.0 (2024-10-15)’ per the release instructions. > On Oct 17, 2024, at 3:22 AM, Xiong Duan wrote: > > I have marked all Jira cases in 1.38 closed. > > Julian Hyde 于2024年10月17日周四 15:20写道： &g

Re: Calcite 1.38.0 still marked as unreleased in Jira

I still need to mark all jira cases in 1.38 closed. Sorry I haven’t had time. I’ll get to it today. Julian > On Oct 16, 2024, at 18:29, Xiong Duan wrote: > > The Jira issue status is RESOLVED at about 1.38, it should be CLOSED. > So I update it. > > Alessandro Solimando 于2024年10月16日周三 16:0

[jira] [Created] (CALCITE-6629) Partitioned outer join (LEFT/RIGHT JOIN ... PARTITION BY)

Julian Hyde created CALCITE-6629: Summary: Partitioned outer join (LEFT/RIGHT JOIN ... PARTITION BY) Key: CALCITE-6629 URL: https://issues.apache.org/jira/browse/CALCITE-6629 Project: Calcite

[ANNOUNCE] Apache Calcite 1.38.0 released

p and feedback. For more information on how to report problems, and to get involved, visit the project website at: https://calcite.apache.org/ Thanks to everyone involved! Julian Hyde, on behalf of the Apache Calcite Team

Re: [DISCUSS] Tidying up Calcite's branches

est wishes, > > Cancai Cai > > > > > 2024年10月7日 07:35，Michael Mior 写道： > > > > > > +1 > > > -- > > > Michael Mior > > > mm...@apache.org > > > > > > > > > On Sat, Oct 5, 2024 at 6:10 PM Julian Hyde wrote: > > > > &

[jira] [Created] (CALCITE-6627) Tidy up Calcite's branches

Julian Hyde created CALCITE-6627: Summary: Tidy up Calcite's branches Key: CALCITE-6627 URL: https://issues.apache.org/jira/browse/CALCITE-6627 Project: Calcite Issue Type

Re: [RESULT] [VOTE] Release apache-calcite-1.38.0 (release candidate 1)

Now I have published a news item, so the main branch is now open for commits. On Mon, Oct 14, 2024 at 6:55 PM Julian Hyde wrote: > > Thanks to everyone who has tested the release candidate and given > their comments and votes. > > The tally is as follows. > > 5 binding +1s

[RESULT] [VOTE] Release apache-calcite-1.38.0 (release candidate 1)

Thanks to everyone who has tested the release candidate and given their comments and votes. The tally is as follows. 5 binding +1s: +1 francischuang (PMC member) +1 jhyde (PMC member) +1 libenchao (PMC member) +1 rubenql (PMC member) +1 zabetak (PMC member) 3 non-binding +1s: +1 cancai (co

[VOTE] Release Apache Calcite 1.38.0 (release candidate 1)

ase this package because... The vote is open for the next 72 hours (closing at 2024-10-13 03:00 UTC) and passes if a majority of at least three +1 votes by PMC members are cast. Here is my vote: +1 jhyde (PMC member) Julian Hyde (release manager)

Re: [DISCUSS] Towards Calcite 1.38.0

For RC2 we need fixes for 6616, 6617 and 6620. I know 6616 is good. Mihai, are the PRs 6617 and 6620 ready to merge? If so, I'll merge them, adjust the release notes and launch RC2. Julian On Thu, Sep 26, 2024 at 11:00 AM Julian Hyde wrote: > > Where are we on 1.38? Down to 2: 45

Re: [CANCEL] [VOTE] Release Apache Calcite 1.38.0 (release candidate 0)

______ > From: Julian Hyde > Sent: Monday, October 7, 2024 1:55 PM > To: dev@calcite.apache.org > Subject: [CANCEL] [VOTE] Release Apache Calcite 1.38.0 (release candidate 0) > > Thank you to Stamatis, Ruben and Mihai for discovering and logging cases > 6616 [1] and

[CANCEL] [VOTE] Release Apache Calcite 1.38.0 (release candidate 0)

text) * Built from source artifacts and run tests (gradle build) OK * Built from git tag and run tests (./gradlew build) OK * Checked LICENSE, NOTICE, for calcite-core-1.38.0.jar in nexus OK +1 zabetak (PMC member) Best, Stamatis On Sat, Oct 5, 2024 at 10:49 PM Julian Hyde wrote: Thanks for

Re: Checked arithmetic

The operator table doesn’t seem to me like the right place. There’s only one PLUS operator even though it applies to several numeric types. We would want different behaviors for different types; if we did that via the operator table, we would need several PLUS operators and a complicated resolut

[DISCUSS] Tidying up Calcite's branches

The Calcite git repository seems to be cluttered with unused branches. I am especially tired of 'maint-0.4.12', which is eleven years old but comes up every time I type 'git log origin/mai'. I analyzed our branches. There are 37 branches in origin (see https://github.com/apache/calcite/branches/al

Re: [Discussion] Measures that span multiple tables

; > create view __all as > select > coalesce(o.origin_country, c.origin_country) as origin_country, > o.sum_revenue, > c.unique_clickers, > from orders_cube o > full outer join clicks_cube c > on o.origin_country = c.origin_country > ``` > > Yes, this is done at

Re: [VOTE] Release Apache Calcite 1.38.0 (release candidate 0)

38.0-rc0 > when the correct link is > https://github.com/apache/calcite/tree/calcite-1.38.0-rc0 > > On 5/10/2024 4:52 pm, Julian Hyde wrote: > >> The Tag's web link is invalid. > > > > Sorry, I forgot to push the tag. It should work now. > > > > (Plea

Re: [VOTE] Release Apache Calcite 1.38.0 (release candidate 0)

> The Tag's web link is invalid. Sorry, I forgot to push the tag. It should work now. (Please continue to vote. My mistake does not invalidate the vote.) On Fri, Oct 4, 2024 at 9:26 PM Xiong Duan wrote: > > +1 Xiong Duan(Committer) > > The Tag's web link is invalid. &g

[VOTE] Release Apache Calcite 1.38.0 (release candidate 0)

he release [ ] -1 Do not release this package because... The vote is open for the next 96 hours (closing at 0400 UTC on Wed Oct 9th) and passes if a majority of at least three +1 votes by PMC members are cast. Here is my vote: +1 jhyde (PMC member) Julian Hyde (release manager)

Re: [Discussion] Measures that span multiple tables

of challenges here: > Efficiently dealing with so many columns? > Is it possible for an optimizer rule to prune the unused join conditions? > Is there sleeker syntax that would make defining such a view more tenable? > > Does such complexity belong as a fundamental concept like Meas

Re: Checked arithmetic

> This will probably require implementing some new Expression methods in > linq4j, since I don't think many of the checked arithmetic functions exist I would be surprised if new Expression methods are required; I think new methods in SqlFunctions (involved via Expressions.call) will be sufficien

Re: Serialisation of optimised query plans

No, that would not be acceptable. EnumerableInterpretable#getBindable is a package-protected method with no javadoc or tests. If you "relax" the visibility modifier it becomes a public API and Calcite committers are responsible for maintaining its behavior in perpetuity. You need to come up with a

Re: Checked arithmetic

I don't know what the SQL standard says. I suspect that most DBMS use checked arithmetic. Because, as you say, people use a DBMS for transactions such as managing bank accounts. But some people want to use SQL as a high-performance distributed data-centric computation language, and these people wi

Re: vulnerabilities: dependency scan

Can someone remind me — is there a Gradle task to update dependencies? (Analogous to 'mvn versions:update-properties’.) If so, we should do this every release. Julian > On Oct 2, 2024, at 9:06 AM, Xiong Duan wrote: > > Hi, Hugh Pearse. Thanks for checking the dependency's vulnerabilities >

Re: [Discussion] Measures that span multiple tables

Good question - thanks for asking. The short answer is that measures that span tables work, but they aren’t quite as convenient as measures in a single table. When designing Measures in SQL I knew that measures sometimes span tables - star schemas are a case in point - but decided to make measu

[jira] [Created] (CALCITE-6602) Deadlock while loading class SqlTypeFixture

Julian Hyde created CALCITE-6602: Summary: Deadlock while loading class SqlTypeFixture Key: CALCITE-6602 URL: https://issues.apache.org/jira/browse/CALCITE-6602 Project: Calcite Issue Type

Re: [DISCUSS] Towards Calcite 1.38.0

Tue, Sep 17, 2024 at 8:16 PM Mihai Budiu wrote: > > > I am now at Current, the confluent conference, but I hope to find some > > time on Friday to do a few. > > > > From: Julian Hyde > > Sent: Tuesday, September 17, 2024 12:08

Re: [DISCUSS] Vote format

eady use. > > For what concerns jira id vs github username vs "real" names, I have had > some troubles in the past, and the community (luckily!) keeps growing, so > it would be nice to have a better way to connect the three easily. > > Best regards, > Alessandro > &g

[jira] [Created] (CALCITE-6598) In RelDataTypeSystem, deprecate methods getMaxNumericScale and getMaxNumericPrecision

Julian Hyde created CALCITE-6598: Summary: In RelDataTypeSystem, deprecate methods getMaxNumericScale and getMaxNumericPrecision Key: CALCITE-6598 URL: https://issues.apache.org/jira/browse/CALCITE-6598

[jira] [Created] (CALCITE-6596) Enable function-level cache by default

Julian Hyde created CALCITE-6596: Summary: Enable function-level cache by default Key: CALCITE-6596 URL: https://issues.apache.org/jira/browse/CALCITE-6596 Project: Calcite Issue Type: Bug

Re: Discussion: Calcite's standard for function argument conversion

There was a discussion a while ago where we decided that type resolution should decide which overload of the method was being called - and therefore the type that each argument needs to be converted to. And it should decide how to convert the argument to the parameter type. (I use the words ‘arg

Re: [DISCUSS] Towards Avatica 1.26.0

gt;> - Multi-versioned JAR or some custom classloading shenanigan to the same >> effect >> - Adding and requiring a compatibility JVM option to run on Java 23. >> >> Adding and requiring the compatibility JVM option is the least work, and >> it's likely necessary any

Re: Question regarding calcite logical algebra's ordinal place holder

Are you interested in changing (1) how field references are represented in RelNodes, (2) how field references are printed in plans, (3) how references to fields are created when you are building a tree of RelNodes. (1) would be a huge disruptive change (and require us to decide what to do when

Re: [DISCUSS] Towards Avatica 1.26.0

> Apache Pig hasn't released a new version for a long time. We should consider removing the Pig adapter at some point. Also upgrade the Spark adapter to a version that uses Hadoop 3.x rather than Hadoop 2.x.

Re: [DISCUSS] Towards Avatica 1.26.0

lting in extra security (even if it is > deprecated), should we remove it only for java 23? > Kind regards, David > > From: Ruben Q L > Date: Thursday, 19 September 2024 at 19:46 > To: dev@calcite.apache.org > Subject: [EXTERNAL] Re: [DISCUSS] Towards Avatica 1.26.0 >

Re: [DISCUSS] Towards Avatica 1.26.0

hould we remove it only for java 23? > Kind regards, David > > From: Ruben Q L > Date: Thursday, 19 September 2024 at 19:46 > To: dev@calcite.apache.org > Subject: [EXTERNAL] Re: [DISCUSS] Towards Avatica 1.26.0 > +1, I think the proposed plan seems reasonable. > >

[jira] [Created] (CALCITE-6590) Remove use of Java SecurityManager in Avatica

Julian Hyde created CALCITE-6590: Summary: Remove use of Java SecurityManager in Avatica Key: CALCITE-6590 URL: https://issues.apache.org/jira/browse/CALCITE-6590 Project: Calcite Issue Type

[DISCUSS] Towards Avatica 1.26.0

While working towards releasing Calcite 1.38.0, I noticed that JDK 23 has been released, and decided to try to upgrade Calcite to support it[1]. And I found myself blocked by an Avatica bug, namely that Avatica uses a getSubject method that has been deprecated for some time and finally disabled in

Re: Questions Regarding Implementing LIMIT Clause Pushdown in Apache Calcite JDBC Driver

By the way, your messages keep on going to moderation. To receive replies, and to remove the effort/delay of moderation, please subscribe to the dev list. Julian > On Sep 17, 2024, at 23:44, Julian Hyde wrote: > > FilterableTable and ProjectFikterTable were designed to make simp

  1   2   3   4   5   6   7   8   9   10   >