Bruce Momjian wrote:
>
> > > I am confused. Do you want one flat query and want to pass the whole
> > > thing into the optimizer? That brings up some questions:
> >
> > No. I just want to follow Tom's way: I would like to see new
> > SubSelect node as shortened version of struct Query (or use
> > Query structure for each subquery - no matter for me), some
> > subquery-related stuff added to Query (and SubSelect) to help
> > optimizer to start, and see
>
> OK, so you want the subquery to actually be INSIDE the outer query
> expression. Do they share a common range table? If they don't, we
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
No.
> could very easily just fly through when processing the WHERE clause, and
> start a new query using a new query structure for the subquery. Believe
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
... and filling some subquery-related stuff in upper query structure -
still don't know what exactly this could be -:)
> me, you don't want a separate SubQuery-type, just re-use Query for it.
> It allows you to call all the normal query stuff with a consistent
> structure.
No objections.
>
> The parser will need to know it is in a subquery, so it can add the
> proper target columns to the subquery, or are you going to do that in
I don't think that we need in it, but list of correlation clauses
could be good thing - all in all parser has to check all column
references...
> the optimizer. You can do it in the optimizer, and join the range table
> references there too.
Yes.
> > typedef struct A_Expr
> > {
> > NodeTag type;
> > int oper; /* type of operation
> > * {OP,OR,AND,NOT,ISNULL,NOTNULL} */
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > IN, NOT IN, ANY, ALL, EXISTS here,
> >
> > char *opname; /* name of operator/function */
> > Node *lexpr; /* left argument */
> > Node *rexpr; /* right argument */
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > and SubSelect (Query) here (as possible case).
> >
> > One thought to follow this way: RULEs (and so - VIEWs) are handled by using
> > Query - how else can we implement VIEWs on selects with subqueries ?
>
> Views are stored as nodeout structures, and are merged into the query's
> from list, target list, and where clause. I am working out
> readfunc,outfunc now to make sure they are up-to-date with all the
> current fields.
Nice! This stuff was out-of-date for too long time.
> > BTW, is
> >
> > select * from A where (select TRUE from B);
> >
> > valid syntax ?
>
> I don't think so.
And so, *rexpr can be of Query type only for oper "in" OP, IN, NOT IN,
ANY, ALL, EXISTS - well.
(Time to sleep -:)
Vadim
