Earlier I started working on recursive queries. Unfortunately due to other
work I haven't had a chance to look at it in about a week. I probably won't be
back on it for another week.
Here's a work-in-progress patch for review. If anyone else wants to hack on it
while I'm distracted that's fine. Hopefully there'll still be some work for me
to do when I get back to it :)
I haven't written up a plan for the next step yet so there's some planning
work to be done first. I think the first thing is to force the subqueries to
be planned individually as Initplans instead of being inlined directly into
the query to avoid duplicated plans (though a cost-based heuristic is needed
to determine when inline is advantageous). Once we have that the patch might
actually be worth applying as it represents good support for non-recursive
WITH clauses.
If not I would love to get some feedback on whether I'm on the wrong track
anywhere.
In particular the issues I'm nervous about is whether I'm storing the right
kinds of information in the right places, such as when it comes to using the
pstate versus nodes of the parse tree. Also whether I'm doing work at the
right phase when it comes to parse versus analysis/transformation versus
postponing work for later in the optimizer and executor.
One thing that isn't working the way I was expecting is that I thought storing
the list of common table expression names in scope in the pstate would have
the right semantics and it isn't. It has to build up a list of cte names that
are in scope from all parent scopes. pstates are inherited when parsing
subqueries and reset to saved copies afterwards which seemed like the right
place. However:
postgres=# with a(x) as (select 1) select * from a;
x
---
1
(1 row)
postgres=# with a(x) as (select 1) select * from (select * from a) as x;
ERROR: relation "a" does not exist
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
