Thread

Re: [HACKERS] subselect

Vadim B. Mikheev <vadim@sable.krasnoyarsk.su> — 1998-01-05T22:18:11Z

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