Actually yes, I meant adding param names in the RexNode itself. I guess
there are valid reasons for why this might be a bad idea so I am not going
to insist on this.
Indeed allowing ('.') field accesses on top of parameters (named or
positional) is not so intuitive given that most of the time
When you say "keep the plan as independent as possible from statement
and other parts of the execution", if you propose to achieve that by
adding names into the RexNodes representing parameters, I don't agree.
I think that RelNode/RexNode should operate based on internal offsets
(retaining names,
I don't know if there is already an issue around this topic, I think not.
Now regarding point (b) I would prefer to keep the plan as independent as
possible from statement and other parts of the execution.
Other than that I encountered a few use-cases where named parameters may be
a better fit:
It’s worth separating this into (a) what the parser should do (i.e. how we
represent this in SqlNode land) and (b) how we represent this in
RexNode/RelNode land.
I think the parser should generate some flavor of SqlDynamicParam. Currently
these only have ‘int index’ but we’d need to hold
Hey Stamatis,
thanks for your help.
Am 18.02.2020 um 19:34 schrieb Stamatis Zampetakis:
Hi Christian,
Long story short: maybe you can achieve what you want by adding a new type
of RexNode. From what I remember quoting is applied to identifiers (schema,
table, column names) so maybe if OLD/NEW
Hi Christian,
Long story short: maybe you can achieve what you want by adding a new type
of RexNode. From what I remember quoting is applied to identifiers (schema,
table, column names) so maybe if OLD/NEW are parameters (e.g.,
RexNamedParam) then possibly it does not make sense to quote them.
My issue is not about parsing. I already have the relational model, I
parsed a query to which I want to add add a condition to a RelNode. Now I
want to add a RexNode to the LogicalFilter node that renders to:
NEW."somecolumn"
How would I construct a RexNode that renders to that when converting
If you want to make NEW a normal sql identifier, you should override it in
the parser to make it unreserved.
Christian Beikov 于2020年2月18日 周二下午3:11写道：
> Hey Danny,
>
> it's not a view, it's a variable in PL/SQL with a row type. The thing
> is, variable names must not be quoted, but I have no idea
Hey Danny,
it's not a view, it's a variable in PL/SQL with a row type. The thing
is, variable names must not be quoted, but I have no idea how to avoid
quoting for this single use case with the relational algebra model in
Calcite.
Regards,
Christian
Am 18.02.2020 um 04:22 schrieb Danny
From the case you gave, the “variable” seems a view ? Sorry I’m not familiar
with the traditional RDBMS.
Best,
Danny Chan
在 2020年2月17日 +0800 PM1:27，Christian Beikov ，写道：
> Hello,
>
> I asked this before but I guess the question got too big, so I thought
> splitting it up might be better.
>
> I
Hello,
I asked this before but I guess the question got too big, so I thought
splitting it up might be better.
I am trying to generate a query from a relational model on which I did a
few tranformations but I don't know how to refer to a "variable".
In a SQL trigger, there usually are two
11 matches
Mail list logo
