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
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
+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.
+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
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
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:
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
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
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
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
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
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
12 matches
Mail list logo
