Hi Andrei,
As you correctly noticed the extra projection column comes from the ORDER
BY clause.
In order to understand why have a look at the Javadoc of RelRoot class (
Unfortunately I don't have an answer, but just a minor point that when you
post links to specific lines of code, it's helpful if that link is to a
specific revision. You can press the "y" shortcut to get this link (pasted
below).
Hello,
I would like to understand how exactly generic map type (_MAP) works
with select
* expression. Say I have the following query (on document database) :
-- first query: 2 projectionsselect * from elastic.zips order by
_MAP['state'] -- second query: single projectionselect _MAP['state']
Zoltan Haindrich created CALCITE-2611:
-
Summary: Code generation fails if one side of an or contains
unknown
Key: CALCITE-2611
URL: https://issues.apache.org/jira/browse/CALCITE-2611
Project:
An AvaticaParameter with a null classname sounds wrong to me. We should
know the type (per the schema) for some variable, regardless of whether
or not it is nullable.
If you can put together a unit test showing what you're seeing in
Avatica, that would go an extremely long way. It may also
I've logged a JIRA for the first bug, with a fix proposal -
https://issues.apache.org/jira/browse/CALCITE-2609.
But the case with AvaticaParameter NPE still remains unclear for me - in
terms of design. Help needed :)
On Wed, Oct 3, 2018 at 4:14 PM ptr.bo...@gmail.com
wrote:
> As for the nulls
Arina Ielchiieva created CALCITE-2610:
-
Summary: AssertionError when group by ordinal in select star query
Key: CALCITE-2610
URL: https://issues.apache.org/jira/browse/CALCITE-2610
Project:
Piotr Bojko created CALCITE-2609:
Summary: Dynamic parameters ? pushed to underlying jdbc schema
Key: CALCITE-2609
URL: https://issues.apache.org/jira/browse/CALCITE-2609
Project: Calcite
