OK, I have created the SubLink structure with supporting routines, and
have added code to create the SubLink structures in the parser, and have
added Query->hasSubLink.

I changed gram.y to support:

	(x,y,z) OP (subselect)

where OP is any operator.  Is that right, or are we doing only certain
ones, and of so, do we limit it in the parser?

I still need to add code to handle SubLink fields in the Where clause
and other supporting code, but it should be enough for Vadim to start
coding if he wants to.  I also need to add Var->sublevels_up.

-- 
Bruce Momjian
maillist@candle.pha.pa.us

Sat, 17 Jan 1998 00:00:50 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
subselects coding started
Bruce Momjian wrote:

> OK, I have created the SubLink structure with supporting routines, and
> have added code to create the SubLink structures in the parser, and have
> added Query->hasSubLink.
>
> I changed gram.y to support:
>
>         (x,y,z) OP (subselect)
>
> where OP is any operator.  Is that right, or are we doing only certain
> ones, and of so, do we limit it in the parser?

Seems like we would want to pass most operators and expressions through
gram.y, and then call elog() in either the transformation or in the
optimizer if it is an operator which can't be supported.

                                           - Tom


Sat, 17 Jan 1998 05:42:45 +0000
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Re: [HACKERS] subselects coding started
> 
> Bruce Momjian wrote:
> 
> > OK, I have created the SubLink structure with supporting routines, and
> > have added code to create the SubLink structures in the parser, and have
> > added Query->hasSubLink.
> >
> > I changed gram.y to support:
> >
> >         (x,y,z) OP (subselect)
> >
> > where OP is any operator.  Is that right, or are we doing only certain
> > ones, and of so, do we limit it in the parser?
> 
> Seems like we would want to pass most operators and expressions through
> gram.y, and then call elog() in either the transformation or in the
> optimizer if it is an operator which can't be supported.
> 

That's what I thought.

-- 
Bruce Momjian
maillist@candle.pha.pa.us

Sat, 17 Jan 1998 11:00:25 -0500 (EST)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] subselects coding started
Thomas G. Lockhart wrote:
> 
> Bruce Momjian wrote:
> 
> > OK, I have created the SubLink structure with supporting routines, and
> > have added code to create the SubLink structures in the parser, and have
> > added Query->hasSubLink.
> >
> > I changed gram.y to support:
> >
> >         (x,y,z) OP (subselect)
> >
> > where OP is any operator.  Is that right, or are we doing only certain
> > ones, and of so, do we limit it in the parser?
> 
> Seems like we would want to pass most operators and expressions through
> gram.y, and then call elog() in either the transformation or in the
> optimizer if it is an operator which can't be supported.

Not in optimizer, in parser, please.
Remember that for <> SubLink->useor must be TRUE and this is parser work
(optimizer don't know about "=", "<>", etc but only about Oper nodes).

IN ("=" ANY) and NOT IN ("<>" ALL) transformations are also parser work.

Vadim

Sun, 18 Jan 1998 19:27:09 +0700
"Vadim B. Mikheev" <vadim@sable.krasnoyarsk.su>
Re: [HACKERS] subselects coding started