Re: [HACKERS] Re: subselects

Bruce Momjian wrote:
>
> We need a new Node structure, call it Sublink:
>
>         int     linkType        (IN, NOTIN, ANY, EXISTS, OPERATOR...)
>         Oid     operator        /* subquery must return single row */
>         List    *lefthand;      /* parent stuff */
>         Node    *subquery;      /* represents nodes from parser */
>         Index   Subindex;       /* filled in to index Query->subqueries */

Ok, I agreed that it's better to have new node and don't put subquery stuff
into Expr node.

int linkType
        is one of EXISTS, ANY, ALL, EXPR. EXPR is for the case of expression
        subqueries (following Sybase naming) which must return single row -
        (a, b, c) = (subquery).
        Note again, that there are no linkType for IN and NOTIN here.
        User' IN and NOT IN must be converted to = ANY and <> ALL by parser.

We need not in Oid operator! In all cases we need in

List *oper
        list of Oper nodes for each of a, b, c, ... and operator (=, ...)
        corresponding to data type of a, b, c, ...

List *lefthand
        is list of Var/Const nodes - representation of (a, b, c, ...)

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 ?

>
> Also, when parsing the subqueries, we need to keep track of correlated
> references.  I recommend we add a field to the Var structure:
>
>         Index   sublevel;       /* range table reference:
>                                    = 0  current level of query
>                                    < 0  parent above this many levels
>                                    > 0  index into subquery list
>                                  */
>
> This way, a Var node with sublevel 0 is the current level, and is true
> in most cases.  This helps us not have to change much code.  sublevel =
> -1 means it references the range table in the parent query. sublevel =
> -2 means the parent's parent. sublevel = 2 means it references the range
> table of the second entry in Query->subqueries.  Varno and varattno are
> still meaningful.  Of course, we can't reference variables in the
> subqueries from the parent in the parser code, but Vadim may want to.
                                                     ^^^^^^^^^^^^^^^^^
No. So, just use sublevel >= 0: 0 - current level, 1 - one level up, ...
sublevel is for optimizer only - executor will not use it.

>
> When doing a Var lookup in the parser, we look in the current level
> first, but if not found, if it is a subquery, we can look at the parent
> and parent's parent to set the sublevel, varno, and varatno properly.
>
> We create no phantom range table entries in the subquery, and no phantom
> target list entries.   We can leave that all for the upper optimizer.

Ok.

Vadim