Re: [HACKERS] Re: subselects

Ok. I don't see how Query->subqueries could me help, but I foresee
that Query->sublinks can do it. Could you add this ?

Bruce Momjian wrote:
>
> >
> > What is Node *subquery ?
> > In optimizer we need either in Subindex (to get subquery from Query->subqueries
> > when beeing in Sublink) or in Node *subquery inside Sublink itself.
> > BTW, after some thought I don't see how Query->subqueries will be usefull.
> > So, may be just add bool hassubqueries to Query (and Query *parentQuery)
> > and use Query *subquery in Sublink, but not subindex ?
>
> OK, I originally created it because the parser would have trouble
> filling in a List* field in SelectStmt while it was parsing a WHERE
> clause.  I decided to just stick the SelectStmt* into Sublink->subquery.
>
> While we are going through the parse output to fill in the Query*, I
> thought we should move the actual subquery parse output to a separate
> place, and once the Query* was completed, spin through the saved
> subquery parse list and stuff Query->subqueries with a list of Query*
> for the subqueries.  I thought this would be easier, because we would
> then have all the subqueries in a nice list that we can manage easier.
>
> In fact, we can fill Query->subqueries with SelectStmt* as we process
> the WHERE clause, then convert them to Query* at the end.
>
> If you would rather keep the subquery Query* entries in the Sublink
> structure, we can do that.  The only issue I see is that when you want
> to get to them, you have to wade through the WHERE clause to find them.
> For example, we will have to run the subquery Query* through the rewrite
> system.  Right now, for UNION, I have a nice union List* in Query, and I
> just spin through it in postgres.c for each Union query.  If we keep the
> subquery Query* inside Sublink, we have to have some logic to go through
> and find them.
>
> If we just have an Index in Sublink to the Query->subqueries, we can use
> the nth() macro to find them quite easily.
>
> But it is up to you.  I really don't know how you are going to handle
> things like:
>
>         select *
>         from taba
>         where x = 3 and y = 5 and (z=6 or q in (select g from tabb ))

No problems.

>
> My logic was to break the problem down to single queries as much as
> possible, so we would be breaking the problem up into pieces.  Whatever
> is easier for you.

Vadim