Thread

1. subselects coding started

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-01-17T05:00:50Z

   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
   
   

2. Re: [HACKERS] subselects coding started

   Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-01-17T05:42:45Z

   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
   
   
   

3. Re: [HACKERS] subselects coding started

   Bruce Momjian <maillist@candle.pha.pa.us> — 1998-01-17T16:00:25Z

   > 
   > 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
   
   

4. Re: [HACKERS] subselects coding started

   Vadim B. Mikheev <vadim@sable.krasnoyarsk.su> — 1998-01-18T12:27:09Z

   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