[jira] [Created] (CALCITE-3520) Type cast from primitive to box is not correct

Feng Zhu created CALCITE-3520: - Summary: Type cast from primitive to box is not correct Key: CALCITE-3520 URL: https://issues.apache.org/jira/browse/CALCITE-3520 Project: Calcite Issue Type: Bug

[jira] [Created] (CALCITE-3519) `inheritPath` of `RelHint` represented by `ImmutableBitSet` may be incomplete.

Shuo Cheng created CALCITE-3519: --- Summary: `inheritPath` of `RelHint` represented by `ImmutableBitSet` may be incomplete. Key: CALCITE-3519 URL: https://issues.apache.org/jira/browse/CALCITE-3519

[jira] [Created] (CALCITE-3518) Use List instead of BitSet to keep inheritPath in RelHint

Danny Chen created CALCITE-3518: --- Summary: Use List instead of BitSet to keep inheritPath in RelHint Key: CALCITE-3518 URL: https://issues.apache.org/jira/browse/CALCITE-3518 Project: Calcite

Re: Reading in Postgres Metadata

Thanks for the reply Julian! I should post more details: right now we have a Metadata class which implements the Metadata spec. All of that seems to work fine. Where we are stuck is in how to read the information_schema metadata from JDBC into the planner. One hackish solution is to open a DB

Re: Reading in Postgres Metadata

May need to be a new type of metadata (i.e. a class that implements Metadata and is acquired via RelMetadataQuery) [1] [2]. Julian [1] https://calcite.apache.org/apidocs/org/apache/calcite/rel/metadata/Metadata.html

Reading in Postgres Metadata

Hi All, We have security type information that we want to bring into the optimizer. Consider the query: SELECT a FROM a,b where a.id=b.id AND a.p > 10; We want the optimizer to know that a.id, b.id are "public" attributes, and a.p is a private attribute. Currently we have type information stored

[jira] [Created] (CALCITE-3517) DiffRepository spends too much time writing XML, makes some tests 5x slower

Julian Hyde created CALCITE-3517: Summary: DiffRepository spends too much time writing XML, makes some tests 5x slower Key: CALCITE-3517 URL: https://issues.apache.org/jira/browse/CALCITE-3517

Re: Re: [DISCUSS] Disable Travis and Appveyor for Avatica and Avatica-Go

Agree, AppVeyor takes more time for queueing. We can remove AppVeyor and keep Travis for a while. - Haisheng -- 发件人：Vladimir Sitnikov 日　期：2019年11月19日 05:42:54 收件人：Apache Calcite dev list 主　题：Re: [DISCUSS] Disable Travis and Appveyor

Re: [DISCUSS] Disable Travis and Appveyor for Avatica and Avatica-Go

Francis, thanks for raising this up. +1 for disabling AppVeyor I think we should need to keep Travis around for a while to evaluate how GitHub Actions work. Frankly speaking, I find Travis logs more responsive and a bit easier to see at the moment (e.g. they are colored, etc, etc). >integration

[DISCUSS] Disable Travis and Appveyor for Avatica and Avatica-Go

Vladimir recently set up Github actions for CI in the avatica repository. These tests now run on Windows, MacOS and Linux. I also did the same for Avatica-Go a couple of months ago. We currently have travis and appveyor enabled in the Avatica repo and travis in the Avatica-Go repo, but given

Re: [jira] [Created] (CALCITE-3510) Implement sqlquery for Redis adapter

I agree with Michael. Let each PR progress at an appropriate speed. Whichever lands first lands first, and it’s not major rework for whoever is second. > On Nov 18, 2019, at 11:27 AM, Michael Mior wrote: > > We already have to convert the pom.xml into a Gradle build script so > I'm not sure I

Re: [jira] [Created] (CALCITE-3510) Implement sqlquery for Redis adapter

We already have to convert the pom.xml into a Gradle build script so I'm not sure I see why merging before or after matters other than where the work might be allocated to. I think this does need careful review though, so I'd imagine that the Gradle migration would naturally land first. -- Michael

[jira] [Created] (CALCITE-3516) Bump net.java.dev.jna:jna to 5.5.0

Vladimir Sitnikov created CALCITE-3516: -- Summary: Bump net.java.dev.jna:jna to 5.5.0 Key: CALCITE-3516 URL: https://issues.apache.org/jira/browse/CALCITE-3516 Project: Calcite Issue

Re: CsvAdapter (Json content) from String / InputStream

Big Thank Guys !!! Even if this CSVAdapter is an "example" its still really usefull :) and with this update it will be a good "out of box" tools usable in many scenario/workflow Yanna Le jeu. 14 nov. 2019 à 21:20, Andrei Sereda a écrit : > > I see that this feature request relates to

[jira] [Created] (CALCITE-3515) Extra files and directory generated

Feng Zhu created CALCITE-3515: - Summary: Extra files and directory generated Key: CALCITE-3515 URL: https://issues.apache.org/jira/browse/CALCITE-3515 Project: Calcite Issue Type: Bug

[jira] [Created] (CALCITE-3514) LatticeTest fails when JdbcSchema re-computes JdbcTables

Feng Zhu created CALCITE-3514: - Summary: LatticeTest fails when JdbcSchema re-computes JdbcTables Key: CALCITE-3514 URL: https://issues.apache.org/jira/browse/CALCITE-3514 Project: Calcite Issue

[jira] [Created] (CALCITE-3513) Unify TableFunction implementor's NullPolicy and its beheavior

Feng Zhu created CALCITE-3513: - Summary: Unify TableFunction implementor's NullPolicy and its beheavior Key: CALCITE-3513 URL: https://issues.apache.org/jira/browse/CALCITE-3513 Project: Calcite

Re: [DISCUSS] Proposal to add API to force rules matching specific rels

Vladimir, Hope it may help you. Currently we applied the next way (just rough description): 1) We created an API to derive possible traits permutations on the basis of children traits (quite similar to one, described in «On Demand trait set request» topic) 2) added a general rule that

[jira] [Created] (CALCITE-3512) Support type cast from Time/TimeStamp to Integer/Long

Feng Zhu created CALCITE-3512: - Summary: Support type cast from Time/TimeStamp to Integer/Long Key: CALCITE-3512 URL: https://issues.apache.org/jira/browse/CALCITE-3512 Project: Calcite Issue