Re: [HACKERS] subselect

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