> No. I just want to follow Tom's way: I would like to see new
> SubSelect node as shortened version of struct Query (or use
> Query structure for each subquery - no matter for me), some
> subquery-related stuff added to Query (and SubSelect) to help
> optimizer to start, and see
This is fine. I thought it would be too much work for the optimizer to
pass a subquery inside the WHERE clause, but if you think you can handle
it, great. I think it is more likely views will work with subqueries if
we do that too, and it is cleaner.
I recommend adding a boolean flag to the rangetable entries to show if
the range was added automatically, meaning it refers to an outer query.
Also, we will need a flag in the Query structure to tell if it is a
subquery, and a pointer to the parent's range table to resolve
references like:
select *
from taba
where col1 = (select col2
from tabb
where col3 = tabb.col4)
In this case, the proper table for col3 can not be determined from the
subquery range table, so we must search the parent range table to add
the proper entry to the child. If we add target entries at the same
time in the parser, we should add a flag to the targetentry structure to
identify it as an entry that will have to have additional WHERE clauses
added to the parent to restrict the join, or we could add those entries
in the parser, but at the time we are processing the subquery, we are
already inside the WHERE clause, so we must be careful.
--
Bruce Momjian
maillist@candle.pha.pa.us