> > 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
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
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.
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
the optimizer. You can do it in the optimizer, and join the range table
references there too.
>
> 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.
>
> BTW, is
>
> select * from A where (select TRUE from B);
>
> valid syntax ?
I don't think so.
--
Bruce Momjian
maillist@candle.pha.pa.us