Re: fields injected after validation

https://calcite.apache.org/javadocAggregate/org/apache/calcite/sql2rel/RelFieldTrimmer.html > On Oct 3, 2023, at 4:11 PM, Guillaume Masse > wrote: > > Ok this makes sense, it's not really a bug, then we fall into the option 2. > > When you mention column pruning is there a specific rule

Re: fields injected after validation

Ok this makes sense, it's not really a bug, then we fall into the option 2. When you mention column pruning is there a specific rule TransformationRule you have in mind? https://github.com/apache/calcite/tree/main/core/src/main/java/org/apache/calcite/rel/rules On Tue, Oct 3, 2023 at 3:59 PM

Re: fields injected after validation

Well, it’s not really “there”. It is removed by the final project. If you want to remove it earlier, do column pruning. (We aren’t aggressive with column pruning because it will introduce extra projects into the plan, therefore make the plan more complex, and increase the planner’s search

Re: fields injected after validation

It's because column2 is a column I created artificially to allow the validation of a query. I normally perform a transformation (RelNode => RelNode) that removes any reference to that column. The problem is that when I convert this Logical Plan back to SQL, it contains references to that column

Re: fields injected after validation

Are you worried that $3 in the first plan has become $4 in the second plan? That’s easily explained because the intermediate table has an extra column, LOWER($1). That pushes up the offset of all columns coming from the right-hand table. > On Oct 3, 2023, at 3:14 PM, Guillaume Masse > wrote:

fields injected after validation

Hi All, I have two tables: t1 and t2 both have a column1 of type t and a column2 that I'm not using I have a function f: t -> t defined in the catalog After validation if I print the logical plan I get the following result: select t1.column1, t2.column1 from company_data."1" t1 join

Looking for feedback on PR for CALCITE-5387

Hey, I recently submitted a draft PR to fix CALCITE-5387 , which can be found here . I am currently waiting on access to update the JIRA ticket, so I thought I'd ping the mailing list for feedback in

Re: Draft: board report for 2023 Q3

+1, and thanks. FYI I’m speaking at Community over Code on 10/9, “Building a semantic/metrics layer using Calcite”. I believe Mihai is giving a talk “Streaming Incremental View Maintenance with Apache Calcite”. Your call whether to include these in this report or the next one. Julian > On

Re: CALCITE-5678/CALCITE-5957: Datetime literal validation

We seem to have reached consensus, and I accept that. But I can’t let Evgeny’s statements about the SQL standard go unchallenged. When the standard says things like “a date literal in a statement shall be in ISO format”[1] it is saying that, to comply with the standard, a DBMS only needs to

Jenkins build is back to normal : Calcite » Calcite-snapshots #632

See

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

See Changes: [Zoltan Haindrich] [CALCITE-4189] Simplify 'p OR (p IS NOT TRUE)' to 'TRUE' -- [...truncated 388.43 KB...]  11.1sec,

Re: CALCITE-5678/CALCITE-5957: Datetime literal validation

Indeed the ideal would be to have some liberty around the supported datetime formats and it would be great if we find people who want to contribute in this direction. However, this discussion is more about converging and taking a decision around CALCITE-5678 and CALCITE-5957. The results of the