Bruce Momjian wrote:
>
> > > OK, here it is. I recommend we pass the outer and subquery through
> > > the parser and optimizer separately.
> >
> > I don't like this. I would like to get parse-tree from parser for
> > entire query and let optimizer (on upper level) decide how to rewrite
> > parse-tree and what plans to produce and how these plans should be
> > merged. Note, that I don't object your methods below, but only where
> > to place handling of this. I don't understand why should we add
> > new part to the system which will do optimizer' work (parse-tree -->
> > execution plan) and deal with optimizer nodes. Imho, upper optimizer
> > level is nice place to do this.
>
> 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
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 ?
BTW, is
select * from A where (select TRUE from B);
valid syntax ?
Vadim