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.

At row level triggers OLD and NEW refer to a single tuple/row at each point
in time. In this case, OLD and NEW are row type variables, or better say
parameters, with the same type as the table. In Calcite, there are
index-based parameters (RexDynamicParam) but not named parameters as the
one you seem to need. I think named parameters are useful in various
scenarios so possibly we could expand the RexNode hierarchy.
In this case to build the plan probably it suffices to create and plug the
parameter wherever you need.

At statement level triggers OLD and NEW refer to set of tuples/rows at each
point in time. In this case, OLD and NEW appear as (temporary)
relations/tables with the same type as the table. In terms of
implementation, I assume that the user defined query acts as a subquery
correlated with OLD/NEW as necessary.
In this case to build the plan probably you need to introduce scan
operations over OLD/NEW tables and create a correlation with the rest of
the query.

Best,
Stamatis

On Tue, Feb 18, 2020 at 7:03 PM Christian Beikov <christian.bei...@gmail.com>
wrote:

> 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 the
> RelNode to SQL. Do I have to extend the SqlDialect to support that?
>
> Danny Chan <yuzhao....@gmail.com> schrieb am Di., 18. Feb. 2020, 15:12:
>
> > If you want to make NEW a normal sql identifier, you should override it
> in
> > the parser to make it unreserved.
> >
> > Christian Beikov <christian.bei...@gmail.com>于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 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 Chan:
> > > >  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 <
> christian.bei...@gmail.com
> > > >,写道:
> > > >> 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 variable "OLD" and "NEW"
> > which I
> > > >> want to be able to refer to. I tried introducing a "transient scan",
> > but
> > > >> unfortunately that won't work because this is not a relation and
> can't
> > > >> be quoted. I will workaround this for now by introducing a temporary
> > > >> relation in the trigger so that I can refer to it, but ideally I
> want
> > to
> > > >> refer to the variable directly.
> > > >>
> > > >> The simplest example SQL that I want to be able to produce would
> look
> > > >> like this:
> > > >>
> > > >> select NEW."some_column"
> > > >>
> > > >> The tricky part here is that NEW is not quoted. I don't know how I
> can
> > > >> represent this in a relation expression.
> > > >>
> > > >> Thanks in advance for any help!
> > > >>
> > > >> Regards,
> > > >>
> > > >> Christian
> > > >>
> > >
> >
>

Reply via email to