Julian Hyde created CALCITE-4594:
Summary: Interpreter returns wrong result when Values has zero
fields
Key: CALCITE-4594
URL: https://issues.apache.org/jira/browse/CALCITE-4594
Project: Calcite
Wow, I just ran into another. ValuesNode.createRows (in the interpreter) [1].
What a coincidence!
Julian
[1]
https://github.com/apache/calcite/blob/4bc916619fd286b2c0cc4d5c653c96a68801d74e/core/src/main/java/org/apache/calcite/interpreter/ValuesNode.java#L56
Hi Ian,
Is there any specific reason or use case that you have to match the root node
and find the parent node in your customized rule?
Thanks,
Haisheng Yuan
On 2021/05/03 20:20:22, Julian Hyde wrote:
> > Is there a way to identify a node as being a root node during RelRule.match?
>
> Not
I am inclined to be brave and idealistic: officially allow records with no
fields, and add enough tests that we know that the existing rules can handle
them.
Of course there is a non-zero risk that we will break some things. But these
things are already broken, because we zero-field RelNodes
> Is there a way to identify a node as being a root node during RelRule.match?
Not currently. One workaround would be to create 'class MyRoot extends
SingleRel', add it as the root of the tree, and write your rules to
match on it.
> Or more generally, is there a way to collect the parents of an
If we add native JSON syntax to SQL, it is very likely that there will
be ambiguities. I think our best path for JSON support is to follow
the SQL standard (and perhaps some extensions made by other major
DBs), which consists of a set of functions to handle JSON. Quite a few
of those functions
Hello,
I am trying to write a rule that matches (among other things) the root of a
RelNode tree.
Unfortunately, it seems that HepRuleCall.parents is only initialized and
populated if the rule extends CommonRelSubExpr, which doesn’t really apply in
my case.
(see:
Hello,
Calcite is used as the parsing layer of a database I am working on. I
noticed that calcite support dot notation and array subscripts in
identifiers as in:
SELECT json_column.person.name.email[5] FROM table
This allows for writing rudimentary Json Path expressions. However, some
Hello,
Another case where it will look a bit cleaner with an empty record is an insert
with values.
Currently a query like INSERT INTO PROJECT(projectId, name) VALUES (?, ?) have
a plan like follow:
TableModify(table=[[PUBLIC, PROJECT]], operation=[INSERT], flattened=[false])
