[jira] [Created] (CALCITE-6424) Enable RLIKE function in MySQL library

xiong duan created CALCITE-6424: --- Summary: Enable RLIKE function in MySQL library Key: CALCITE-6424 URL: https://issues.apache.org/jira/browse/CALCITE-6424 Project: Calcite Issue Type:

Re: GROUP BY ordinals with expand star

OK, please log a jira case. Please describe cases where it should give an error. Describe any pertinent flags. > On May 29, 2024, at 8:58 AM, Itiel Sadeh > wrote: > > Thanks for the response Julian. > > I agree that it is a pretty unuseful use case, but it is a valid SQL as far > as I can

Re: GROUP BY ordinals with expand star

Thanks for the response Julian. I agree that it is a pretty unuseful use case, but it is a valid SQL as far as I can tell. PostgreSQL does support it. Maybe Calcite shouldn't support it, but I think that the error message is a bit unintuitive in this case. Thanks again, Itiel On Tue, May 28,

Re: GROUP BY ordinals with expand star

It doesn’t seem particularly useful to use “*” in a “GROUP BY” query. The query will be invalid if you don’t include all the columns in the GROUP BY clause. (In a few databases, one of which is MySQL, the query “SELECT empno, deptno, sal FROM emp GROUP BY empno” would be valid if “empno” is a

[jira] [Created] (CALCITE-6423) Invalid unparse for CHAR without precision in MySQLDialect

xiong duan created CALCITE-6423: --- Summary: Invalid unparse for CHAR without precision in MySQLDialect Key: CALCITE-6423 URL: https://issues.apache.org/jira/browse/CALCITE-6423 Project: Calcite

GROUP BY ordinals with expand star

Hello calcite team, Consider the following: Let's say I have a table "t" with two columns: "CREATE TABLE t(x int, y int);" Now, the following query will result in validation error: "SELECT * FROM t GROUP BY 1,2", But if I'm not using "*" it will work: "SELECT x, y FROM t GROUP BY 1,2" The issue

[jira] [Created] (CALCITE-6422) RexLiteral.isNullLiteral should be called before RexLiteral.booleanValue in SubstitutionVisitor.mayBeSatisfiable

Mou Wu created CALCITE-6422: --- Summary: RexLiteral.isNullLiteral should be called before RexLiteral.booleanValue in SubstitutionVisitor.mayBeSatisfiable Key: CALCITE-6422 URL:

[jira] [Created] (CALCITE-6421) Calcite Avatica support JDK 22

Sergey Nuyanzin created CALCITE-6421: Summary: Calcite Avatica support JDK 22 Key: CALCITE-6421 URL: https://issues.apache.org/jira/browse/CALCITE-6421 Project: Calcite Issue Type: Bug

EnumerableTableScan array/multiset handling

Hello, in my recent experiments I ran into some issues when trying to unnest an array of struct. The query is roughly this: select t.id, e.value1 from MyTable t, unnest(t.structArray) e EnumerableTableScan#fieldExpression will then try to generate code that converts the value of the

[jira] [Created] (CALCITE-6420) Fix confusing MappingType enum

ZiJie Song created CALCITE-6420: --- Summary: Fix confusing MappingType enum Key: CALCITE-6420 URL: https://issues.apache.org/jira/browse/CALCITE-6420 Project: Calcite Issue Type: Improvement

[jira] [Created] (CALCITE-6419) Invalid unparse for VARCHAR without precision in HiveSqlDialect And SparkSqlDialect

xiong duan created CALCITE-6419: --- Summary: Invalid unparse for VARCHAR without precision in HiveSqlDialect And SparkSqlDialect Key: CALCITE-6419 URL: https://issues.apache.org/jira/browse/CALCITE-6419

[jira] [Created] (CALCITE-6418) Expression with ALL aggregate return unexpected result.

Evgeny Stanilovsky created CALCITE-6418: --- Summary: Expression with ALL aggregate return unexpected result. Key: CALCITE-6418 URL: https://issues.apache.org/jira/browse/CALCITE-6418 Project:

[jira] [Created] (CALCITE-6417) Map value constructor and Array value constructor unparsed incorrectly for HiveSqlDialect

xiong duan created CALCITE-6417: --- Summary: Map value constructor and Array value constructor unparsed incorrectly for HiveSqlDialect Key: CALCITE-6417 URL: https://issues.apache.org/jira/browse/CALCITE-6417

[jira] [Created] (CALCITE-6416) Remove unnecessary SUBSTRING rewrite in SparkSqlDialect

xiong duan created CALCITE-6416: --- Summary: Remove unnecessary SUBSTRING rewrite in SparkSqlDialect Key: CALCITE-6416 URL: https://issues.apache.org/jira/browse/CALCITE-6416 Project: Calcite

[Question] Left Semi Join and SqlToRelConverter

Hi all, I'm exploring extensions to Calcites parser and saw that the Babel parser impl has some nice things I want to work with, namely support for Spark-style LEFT_SEMI_JOINs syntax. Using this parser works for me, but I noticed that when using SqlToRelConverter, converting LEFT_SEMI_JOIN is not

[jira] [Created] (CALCITE-6415) Invalid unparse for TIMESTAMP with HiveSqlDialect

xiong duan created CALCITE-6415: --- Summary: Invalid unparse for TIMESTAMP with HiveSqlDialect Key: CALCITE-6415 URL: https://issues.apache.org/jira/browse/CALCITE-6415 Project: Calcite Issue

RE: Re: CoreFilters.FILTER_REDUCE_EXPRESSIONS issue

> You say that >… > isn't valid SQL. What's wrong with it? It looks valid and correct to > me. Right, this was phrased poorly. I assume this is valid ANSI SQL, but it is not for the versions of Oracle and SQL Server I’m currently working with. To this point I haven’t run into any issues

Re: CoreFilters.FILTER_REDUCE_EXPRESSIONS issue

You say that SELECT code, CASE WHEN code = 'test_val' THEN ABS(val) ELSE NULL END AS absval FROM TEST WHERE CASE WHEN code = 'test_val' THEN ABS(val) > 0 ELSE FALSE END isn't valid SQL. What's wrong with it? It looks valid and correct to me. (I acknowledge that it's neither pretty nor

CoreFilters.FILTER_REDUCE_EXPRESSIONS issue

I'm having an issue with CoreFilters.FILTER_REDUCE_EXPRESSIONS. I'm wondering if this is a problem with the rule, or with how I've set up my logical tree. Conceptually I am trying to use the equivalent of a computed column in a WHERE. Since this isn't legal: SELECT code, CASE WHEN code =

[jira] [Created] (CALCITE-6414) Resolve Snoflake SQL generation of BOOL_OR, BOOL_AND

Justin Swett created CALCITE-6414: - Summary: Resolve Snoflake SQL generation of BOOL_OR, BOOL_AND Key: CALCITE-6414 URL: https://issues.apache.org/jira/browse/CALCITE-6414 Project: Calcite

[jira] [Created] (CALCITE-6413) SqlValidator does not invoke type coercion for both NATURAL and USING join conditions

Maksim Zhuravkov created CALCITE-6413: - Summary: SqlValidator does not invoke type coercion for both NATURAL and USING join conditions Key: CALCITE-6413 URL: https://issues.apache.org/jira/browse/CALCITE-6413

[jira] [Created] (CALCITE-6412) SqlToRelConverter fails to convert SqlMerge AST to relational expression

Pavel Pereslegin created CALCITE-6412: - Summary: SqlToRelConverter fails to convert SqlMerge AST to relational expression Key: CALCITE-6412 URL: https://issues.apache.org/jira/browse/CALCITE-6412

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

See Changes: [Alessandro Solimando] [CALCITE-6340] RelBuilder drops traits when aggregating over duplicate projected fields -- [...truncated 9.10 KB...]

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

See Changes: [guohongyu217] [CALCITE-6400] MAP_ENTRIES function should throw if a key value is null -- [...truncated 473.99 KB...] 5.3sec,3

[jira] [Created] (CALCITE-6411) Support Collect in ToLogicalConverter

Caican Cai created CALCITE-6411: --- Summary: Support Collect in ToLogicalConverter Key: CALCITE-6411 URL: https://issues.apache.org/jira/browse/CALCITE-6411 Project: Calcite Issue Type:

Re: Apache at Visa Summit

I shall also be speaking at the SF Distributed Systems Meetup in downtown SF on Wednesday May 22nd [3]. This talk will be on a different topic, SQL with Measures. (A preview of the talk that I shall give at SIGMOD in Santiago, Chile, in June.) SF Distributed Systems is a new meetup that I have

Apache at Visa Summit

Visa is a major sponsor of the ASF and is hosting a one-day conference in Foster City, CA, on Thursday (May 16th) to showcase Apache projects [1]. I am giving a talk "Open Source Software Innovation in Advanced Databases and Analytics" [2]. I believe registration is free for ASF committers, and

Community over Code EU 2024: The countdown has started!

[Note: You're receiving this email because you are subscribed to one or more project dev@ mailing lists at the Apache Software Foundation.] We are very close to Community Over Code EU -- check out the amazing program and the special discounts that we have for you. Special discounts You still

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

See Changes: [mbudiu] [CALCITE-6313] Add POWER function for PostgreSQL -- [...truncated 504.19 KB...] at

[jira] [Created] (CALCITE-6410) dateadd(MONTH, 3, date '2016-02-24') parsing failed

Caican Cai created CALCITE-6410: --- Summary: dateadd(MONTH, 3, date '2016-02-24') parsing failed Key: CALCITE-6410 URL: https://issues.apache.org/jira/browse/CALCITE-6410 Project: Calcite Issue

[jira] [Created] (CALCITE-6409) Character types and Boolean types are comparable

Caican Cai created CALCITE-6409: --- Summary: Character types and Boolean types are comparable Key: CALCITE-6409 URL: https://issues.apache.org/jira/browse/CALCITE-6409 Project: Calcite Issue

[jira] [Created] (CALCITE-6408) Not-null ThreadLocal

Julian Hyde created CALCITE-6408: Summary: Not-null ThreadLocal Key: CALCITE-6408 URL: https://issues.apache.org/jira/browse/CALCITE-6408 Project: Calcite Issue Type: Improvement

Re: [Question][RelTree] Collecting Column Origins Deeply

Hi Stamatis, Thanks for the quick reply, this seems to be exactly what I was looking for! Is there any literature / articles you could recommend on this topic of optimizations and preprocessing? I've found reading through Calcite docs and source code to be a tad tedious, and wondering if there is

[jira] [Created] (CALCITE-6407) DECIMAL types with scale > precision should be tested

Mihai Budiu created CALCITE-6407: Summary: DECIMAL types with scale > precision should be tested Key: CALCITE-6407 URL: https://issues.apache.org/jira/browse/CALCITE-6407 Project: Calcite

[jira] [Created] (CALCITE-6406) Negative scales for DECIMAL types are not tested

Mihai Budiu created CALCITE-6406: Summary: Negative scales for DECIMAL types are not tested Key: CALCITE-6406 URL: https://issues.apache.org/jira/browse/CALCITE-6406 Project: Calcite Issue

[jira] [Created] (CALCITE-6405) TO_TIMESTAMP doesn't work

Oleg Alekseev created CALCITE-6405: -- Summary: TO_TIMESTAMP doesn't work Key: CALCITE-6405 URL: https://issues.apache.org/jira/browse/CALCITE-6405 Project: Calcite Issue Type: Bug

Re: [Question][RelTree] Collecting Column Origins Deeply

Hey Logan, Many parts of Calcite such as rules and metadata providers rely on the assumption that the RelNode tree does not contain subqueries. This is achieved by using the SubQueryRemoveRule [1] early on during the optimization process. Another pretty common preprocessing step is query

[Question][RelTree] Collecting Column Origins Deeply

Hi all, I am new to Calcite so apologies for what might be a basic question. I'm working with the RelTree, and trying to understand the standard way to collect column origins for a RelNode. My current strategy to collect column origins for some arbitrary node is to use the node's metadataQuery

Re: Custom non-sql data types?

That's exactly the kind of input I'm looking for! Functions certainly could work for me, as long as the optimization propagates just as well as it would with a literal (and sounds like yes, if that's the basis for geospatial support). On Thu, May 9, 2024 at 1:55 PM Julian Hyde wrote: > Are you

Re: Custom non-sql data types?

Are you sure that you need your constant values to be instances of RexLiteral? A call to a 'constructor function' might do just as well. In Calcite's geospatial support, there is no literal for the GEOMETRY type. Expressions such as ST_PointFromText('POINT(-71.064544 42.28787)') are commonplace

Custom non-sql data types?

Hi all, I'm evaluating if Calcite is a good fit as a query planner for my database project, and would appreciate some high-level pointers on where to look in the source to figure out how to do what I need. Or, alternatively, confirmation if it's not feasible. My system is relational but not SQL,

[jira] [Created] (CALCITE-6404) update support subquery

colagy wang created CALCITE-6404: Summary: update support subquery Key: CALCITE-6404 URL: https://issues.apache.org/jira/browse/CALCITE-6404 Project: Calcite Issue Type: Improvement

Re: Bug(about timestamp dataType) - 20240509

Hi developer, Please log it in Calcite Jira: https://issues.apache.org/jira/browse/CALCITE and also use code reformat when description. 小艾 <854413...@qq.com.invalid> 于2024年5月9日周四 16:30写道： > Version 1.36.0

[jira] [Created] (CALCITE-6403) Rule AGGREGATE_EXPAND_DISTINCT_AGGREGATES is unsound

Mihai Budiu created CALCITE-6403: Summary: Rule AGGREGATE_EXPAND_DISTINCT_AGGREGATES is unsound Key: CALCITE-6403 URL: https://issues.apache.org/jira/browse/CALCITE-6403 Project: Calcite

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

See

Re: About calcite’s processing of metadata information

Do you know which metadata? For validation it is mostly using interface Schema (by which it accesses table definitions and their columns). For optimization it might use other metadata such as existence of keys, row counts, etc. There are various implementations of Schema - including with

About calcite’s processing of metadata information

Hello everyone in the calcite community, I am doing some interesting things with calcite. There is a question I would like to ask, but I have not seen this part of the calcite code, so I don't know if it is appropriate to ask it here. When I use calcite's sqlValidator.validate interface to verify

[jira] [Created] (CALCITE-6402) Aggregates implied in grouping sets have a wrong nullability at validation stage

Claude Brisson created CALCITE-6402: --- Summary: Aggregates implied in grouping sets have a wrong nullability at validation stage Key: CALCITE-6402 URL: https://issues.apache.org/jira/browse/CALCITE-6402

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

See Changes: [mbudiu] [CALCITE-6361] Uncollect.deriveUncollectRowType throws AssertionFailures -- [...truncated 9.17 KB...] > Task

[jira] [Created] (CALCITE-6401) JDBC adapter cannot push down joins with complex JOIN condition

Ulrich Kramer created CALCITE-6401: -- Summary: JDBC adapter cannot push down joins with complex JOIN condition Key: CALCITE-6401 URL: https://issues.apache.org/jira/browse/CALCITE-6401 Project:

Re: [DISCUSS] Towards Calcite 1.37.0

Thanks for driving this release, sergey! -- Best regards, Hongyu On Tue, May 7, 2024 at 3:42 PM Sergey Nuyanzin wrote: > Thanks a lot Francis! > > I was able to finish it, > now the main code freeze is over and commits can be resumed. Thank you all > who was involved in the release of 1.37.0.

Re: [DISCUSS] Towards Calcite 1.37.0

Thanks a lot Francis! I was able to finish it, now the main code freeze is over and commits can be resumed. Thank you all who was involved in the release of 1.37.0. On Tue, May 7, 2024 at 1:40 AM Francis Chuang wrote: > I added you as an Administrator in Jira, you should be able to do it now.

Re: [DISCUSS] Towards Calcite 1.37.0

I added you as an Administrator in Jira, you should be able to do it now. Francis On 7/05/2024 8:38 am, Sergey Nuyanzin wrote: Hi everyone I'm in process of publishing Calcite release and I need PMC help for jira It looks like I don't have enough grants to mark release released (I don't have

Re: [DISCUSS] Towards Calcite 1.37.0

Hi everyone I'm in process of publishing Calcite release and I need PMC help for jira It looks like I don't have enough grants to mark release released (I don't have these buttons on that tab) Could someone from PMC please help me with this? On Mon, Apr 29, 2024 at 8:57 AM Sergey Nuyanzin

[RESULT][VOTE] Release Apache Calcite 1.37.0 (release candidate 4)

Thanks to everyone who has tested the release candidate and given their comments and votes. The tally is as follows. 4 binding +1s: Sergey Nuyanzin Stamatis Zampetakis Francis Chuang Michael Mior 1 non-binding -1: Guillaume Masse 1 binding 0s: Ruben Quesada Lopez 1 non-binding 0s: Alessandro

[jira] [Created] (CALCITE-6400) MAP_ENTRIES is not allowed to be empty

Caican Cai created CALCITE-6400: --- Summary: MAP_ENTRIES is not allowed to be empty Key: CALCITE-6400 URL: https://issues.apache.org/jira/browse/CALCITE-6400 Project: Calcite Issue Type: Bug

[jira] [Created] (CALCITE-6399) The predicate IN is transformed by the sqltorelConverter into join

kate created CALCITE-6399: - Summary: The predicate IN is transformed by the sqltorelConverter into join Key: CALCITE-6399 URL: https://issues.apache.org/jira/browse/CALCITE-6399 Project: Calcite

[jira] [Created] (CALCITE-6398) Spark's ifnull function has only one parameter and the return value is Boolean

Caican Cai created CALCITE-6398: --- Summary: Spark's ifnull function has only one parameter and the return value is Boolean Key: CALCITE-6398 URL: https://issues.apache.org/jira/browse/CALCITE-6398

[jira] [Created] (CALCITE-6397) Add NVL2 function (enabled in Spark library)

Caican Cai created CALCITE-6397: --- Summary: Add NVL2 function (enabled in Spark library) Key: CALCITE-6397 URL: https://issues.apache.org/jira/browse/CALCITE-6397 Project: Calcite Issue Type:

[jira] [Created] (CALCITE-6396) Add ADD_MONTHS function (enabled in Spark library)

Caican Cai created CALCITE-6396: --- Summary: Add ADD_MONTHS function (enabled in Spark library) Key: CALCITE-6396 URL: https://issues.apache.org/jira/browse/CALCITE-6396 Project: Calcite Issue

Re: Dynamic Parameters Handling in RelNode

You should be able to do it at the SqlNode stage. You can create a SqlShuttle that replaces your placeholder table name with another table name.

Re: Dynamic Parameters Handling in RelNode

Hi Walaa, Adding onto the last mail: 1) I already have the value of *table_name* parameter with schema and table object to help calcite resolving it while creating RelNode. Is there any way to pass this? But In the translated query the value should be replaced with the key itself. Or Do we

Re: Dynamic Parameters Handling in RelNode

Hi Ravi, RelNodes depend on specific table objects with known schemas. Unless we know that table's schema there is no way to generate the RelNode in the first place. Maybe if you know the schema (data types of the table columns), it is possible to get around the lack of a name, but I do not see

Dynamic Parameters Handling in RelNode

Hello Team, Is there any way in the calcite framework to use runtime variables in Rel Node in order to get the same variable back in the translated query? Basically I want the same variable to be used back as the runtime parameter after query translation. Here I am talking specifically about

[jira] [Created] (CALCITE-6395) Significant precision loss when representing REAL literals

Mihai Budiu created CALCITE-6395: Summary: Significant precision loss when representing REAL literals Key: CALCITE-6395 URL: https://issues.apache.org/jira/browse/CALCITE-6395 Project: Calcite

Re: [VOTE] Release Apache Calcite 1.37.0 (release candidate 4)

Thanks Sergey for preparing this new RC. - Release notes: ok (minor comment left in the PR) - Checksum: ok - Signature: ok - Diff source release and git repository: ok - Build + tests (from both RC commit and source artifacts): ok (also confirmed in a Windows env that the ArrowAdapter test issue

Re: Is it posible to change synthetic input names ($0, $1, etc) in explain plans?

Thanks for your fast response. I've created https://issues.apache.org/jira/browse/CALCITE-6394 to discuss about that.

[jira] [Created] (CALCITE-6394) Be able to use input names instead of $i in explain

Gonzalo Ortiz created CALCITE-6394: -- Summary: Be able to use input names instead of $i in explain Key: CALCITE-6394 URL: https://issues.apache.org/jira/browse/CALCITE-6394 Project: Calcite

Re: [VOTE] Release Apache Calcite 1.37.0 (release candidate 4)

It seems that Sergey has logged https://issues.apache.org/jira/browse/CALCITE-6393 for this. Please add further discussion to that case rather than to this vote thread. > On Apr 30, 2024, at 12:44 AM, Ruben Q L wrote: > > Thanks Guillaume for checking this! > When I looked at this issue on

Re: Is it posible to change synthetic input names ($0, $1, etc) in explain plans?

Gonzalo, I think the implementation is fairly straightforward. You’d write a new implementation of RelWriter. But, as Alessandro says, the specification is the hard part. What *exactly* would you want instead of $0? (Those fields have names, and most of the time they are the same as the user

Re: [VOTE] Release Apache Calcite 1.37.0 (release candidate 4)

+1 (binding) checked signatures and hash, compiled and ran tests. Thanks Sergey! -- Michael Mior mm...@apache.org On Mon, Apr 29, 2024 at 10:56 AM Sergey Nuyanzin wrote: > Hi all, > > The issue CALCITE-6390 with failing of Arrow Adapter tests on Windows while > building from source is fixed.

Re: [VOTE] Release Apache Calcite 1.37.0 (release candidate 4)

+0 (non-binding) due to the ASM issue, I agree it’s an inconvenience but at the same time I agree with Stamatis that the main release artifact is the source code. Thanks Sergey for preparing these RCs, this is what I have checked: - verified gpg signature: OK $ gpg --verify

Re: Is it posible to change synthetic input names ($0, $1, etc) in explain plans?

Hi Gonzalo, what would you expect when $i points to a complex expression from the input relation(s)? It's easier to brainstorm around a concrete running example, would you have one to share? (existing vs sought behavior) Best regards, Alessandro On Tue, 30 Apr 2024 at 12:39, Gonzalo Ortiz

[jira] [Created] (CALCITE-6393) Byte code of SqlFunctions is invalid

Sergey Nuyanzin created CALCITE-6393: Summary: Byte code of SqlFunctions is invalid Key: CALCITE-6393 URL: https://issues.apache.org/jira/browse/CALCITE-6393 Project: Calcite Issue Type:

Is it posible to change synthetic input names ($0, $1, etc) in explain plans?

Hi community, I'm trying to improve explain plans in Apache Pinot and one of the main complaints of our customers is how difficult it is to read the explain plans having to transform the synthetic input names into the corresponding logical field. Is there a way to improve that? Ideally these

Re: [VOTE] Release Apache Calcite 1.37.0 (release candidate 4)

I agree with Guillaume and lean towards a -1. IMHO we should not produce a release with incorrect bytecode (even if this is only detectable by other tools like ASM). Of course, we should try to find the root cause (although it seems quite elusive); but if there is a simple workaround to generate

Re: [VOTE] Release Apache Calcite 1.37.0 (release candidate 4)

My vote is: +1 (binding) - Verified GPG signature - OK - Verified SHA512 - OK - Diffed source release and git repository - OK - Checked release notes on tag (https://github.com/apache/calcite/blob/calcite-1.37.0-rc4/site/_docs/history.md) - OK - Checked year and versions in NOTICE, README and

Regarding the use of Apache Calcite's planner with PostgreSQL

Greetings, Thanks to the suggestions from @Stamatis I was able to fix the build errors and get a successful build. Coming to the main purpose of me trying to use calcite. I am a college student and have been selected to be part of a research project that aims to use Calcite's planner with

Re: [VOTE] Release Apache Calcite 1.37.0 (release candidate 4)

Ubuntu 20.04.6 LTS, jdk1.8.0_261, Gradle wrapper, Gradle 7.6.1 * Checked signatures and checksums OK * Checked diff between repo and artifacts OK * Checked README, NOTICE, LICENSE OK * All source files have ASF headers OK ( grep -RiL "Licensed to the Apache Software Foundation") * No

Re: [VOTE] Release Apache Calcite 1.37.0 (release candidate 4)

Thanks Guillaume for checking this! When I looked at this issue on 1.36, I had the impression that assertions might have a role to play in the error, but I could not confirm this hypothesis. IMO this smells like a JDK bug (or at least it looks like other resolved issues); note that it seems we had

Re: [VOTE] Release Apache Calcite 1.37.0 (release candidate 4)

Hi Guilluame, I played a bit more and I realised that if from commit above I just remove one line with assert (assert map != null) then ArrayIndexOutOfBoundsException disappears same for current main branch, if I remove all lines from SqlFunctions with assert (now there are 3 such lines) then

[jira] [Created] (CALCITE-6392) Support all PostgreSQL 14 date/time patterns for to_date/to_timestamp

Norman Jordan created CALCITE-6392: -- Summary: Support all PostgreSQL 14 date/time patterns for to_date/to_timestamp Key: CALCITE-6392 URL: https://issues.apache.org/jira/browse/CALCITE-6392 Project:

Re: [VOTE] Release Apache Calcite 1.37.0 (release candidate 4)

i follow the procedure described here https://calcite.apache.org/docs/howto.html#making-a-release-candidate started btw I played a bit with git bisect and it shows that the issue java.lang.ArrayIndexOutOfBoundsException: Index 65536 out of bounds for length 297at

Re: [VOTE] Release Apache Calcite 1.37.0 (release candidate 4)

Hi Sergey, thanks for trying that update I confirm I have the same issue with your release at https://repository.apache.org/content/repositories/orgapachecalcite-1231/org/apache/calcite/ https://github.com/MasseGuillaume/asm-remapper-bug/commit/852e4cd246d278db8acf5e997a54619bc4f85fc7 This

Re: [VOTE] Release Apache Calcite 1.37.0 (release candidate 4)

I repeated same procedure with jdk1.8u412 here you can find the jars https://repository.apache.org/content/repositories/orgapachecalcite-1231/org/apache/calcite/ it looks like asm-remapper gives the same result... On Mon, Apr 29, 2024 at 8:41 PM Guillaume Masse wrote: > If you take a look at >

Re: [VOTE] Release Apache Calcite 1.37.0 (release candidate 4)

If you take a look at https://www.openlogic.com/openjdk-downloads?field_java_parent_version_target_id=416_operating_system_target_id=426_architecture_target_id=391_java_package_target_id=All The most recent release is 8u412-b08 If it follows more or less the openjdk schedule:

[jira] [Created] (CALCITE-6391) Apply mapping to RelCompositeTrait does not apply it to wrapped traits

James Duong created CALCITE-6391: Summary: Apply mapping to RelCompositeTrait does not apply it to wrapped traits Key: CALCITE-6391 URL: https://issues.apache.org/jira/browse/CALCITE-6391 Project:

Re: [VOTE] Release Apache Calcite 1.37.0 (release candidate 4)

Thanks for testing Guillaume >Sergey can you give me all the details about your build environment so I >can reproduce that bytecode? >OS / java --version yep, sure Ubuntu 22.04.4 LTS, 1.8.0_372-372 (OpenLogic-OpenJDK 25.372-b07) I will also try to look at it with my set up and the info you've

Re: [VOTE] Release Apache Calcite 1.37.0 (release candidate 4)

-1 (not binding) The bytecode of classfile org/apache/calcite/runtime/SqlFunctions.class is invalid (and only this classfile) I tested all class files from the following artifacts: calcite-core-1.37.0.jar calcite-linq4j-1.37.0.jar avatica-core-1.25.0.jar avatica-metrics-1.25.0.jar This will

[VOTE] Release Apache Calcite 1.37.0 (release candidate 4)

Hi all, The issue CALCITE-6390 with failing of Arrow Adapter tests on Windows while building from source is fixed. Thanks a lot to Caican Can for highlighting the issue Stamatis for quick PR and Ruben and Alessandro for the review! I have created a build for Apache Calcite 1.37.0, release

[CANCEL][VOTE] Release Apache Calcite 1.37.0, release candidate 3)

Cancel this thread, due to CALCITE-6390[1] issue in the build. Will start another vote once the issue will be fixed and merged. [1] https://issues.apache.org/jira/browse/CALCITE-6390 -- Best regards, Sergey

Re: [VOTE] Release Apache Calcite 1.37.0 (release candidate 3)

I'm going to cancel the vote because of CALCITE-6390[1] [1] https://issues.apache.org/jira/browse/CALCITE-6390 On Sun, Apr 28, 2024 at 6:24 PM Sergey Nuyanzin wrote: > one finding I forgot to mention > I noticed that Arrow adapter[1] was merged with skipping of build on > Windows > and it

Re: [DISCUSS] Towards Calcite 1.37.0

Hi everyone, I created RC 3 however as I mentioned in the RC3 thread there is an issue with Arrow adapter that it is not supported on Windows, as a result it is not able to pass tests on Windows. I noticed that there are some links to Arrow docs telling that there is no official support for

Re: [VOTE] Release Apache Calcite 1.37.0 (release candidate 3)

one finding I forgot to mention I noticed that Arrow adapter[1] was merged with skipping of build on Windows and it definitely has issues while testing on Windows, I raised a jira issue for that[2] so in case of Windows currently should follow same way like it is in GHA settings gradle build

[VOTE] Release Apache Calcite 1.37.0 (release candidate 3)

Hi all, I have created a build for Apache Calcite 1.37.0, release candidate 3. Thanks to everyone who has contributed to this release. You can read the release notes here: https://github.com/apache/calcite/blob/calcite-1.37.0-rc3/site/_docs/history.md The commit to be voted upon:

[CANCEL][VOTE] Release Apache Calcite 1.37.0 (release candidate 2)

Cancel this thread, due to CALCITE-6387[1] issue in the build. Will start another vote once the issue will be fixed and merged. [1] https://issues.apache.org/jira/browse/CALCITE-6387 -- Best regards, Sergey

Re: [VOTE] Release Apache Calcite 1.37.0 (release candidate 2)

Thanks Hongyu for finding the issue thanks Alessandro for the confirmation and thanks for all who took the time to vote. I'm going to cancel the vote On Sat, Apr 27, 2024 at 10:05 PM Alessandro Solimando < alessandro.solima...@gmail.com> wrote: > Hi Sergey, > I think it's worth making another

[jira] [Created] (CALCITE-6390) ArrowAdapterTest fails on Windows 11

Sergey Nuyanzin created CALCITE-6390: Summary: ArrowAdapterTest fails on Windows 11 Key: CALCITE-6390 URL: https://issues.apache.org/jira/browse/CALCITE-6390 Project: Calcite Issue Type:

[jira] [Created] (CALCITE-6389) RexBuilder.removeCastFromLiteral does not preserve semantics for decimal literals

Mihai Budiu created CALCITE-6389: Summary: RexBuilder.removeCastFromLiteral does not preserve semantics for decimal literals Key: CALCITE-6389 URL: https://issues.apache.org/jira/browse/CALCITE-6389

Re: [VOTE] Release Apache Calcite 1.37.0 (release candidate 2)

Hi Sergey, I think it's worth making another RC after merging your fix. Testing locally, I discovered another issue for which I filed CALCITE-6388 and an associated PR. Since we are inclined to make another RC it might be worth merging this

<    1   2   3   4   5   6   7   8   9   10   >