subselects coding started
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
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
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
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