Re: Common Table Expressions (WITH RECURSIVE) patch

I am re-sending this message to -hackers from yesterday, because the
first time it didn't appear to make it through. This time I gzipped the
patch. This is just for the archives (and to give context to the
replies), and this message is superseded by Tom's patch here:

http://archives.postgresql.org/pgsql-hackers/2008-09/msg01521.php

On Thu, 2008-09-18 at 12:55 +0900, Tatsuo Ishii wrote:
> Tom, thanks for the review.
>
> Here is an in-progress report. Patches against CVS HEAD attached.
> (uncommented items are work-in-progress).

Here is a patch that is an initial attempt to reorganize the parse tree
representation.

The goal of this patch is to separate the RTEs from the CTEs, so that we
can, for example, have multiple RTEs refer to the same CTE. This will
hopefully allow us to materialize a volatile query once, and have
several RTEs refer to that same value, which will meet the SQL standard.

Notes:

* It makes a p_cte_table in the ParseState, which is a list of
CteTblEntries. This replaces p_ctenamespace, which was a list of
RangeSubselects.

* It copies the p_cte_table into Query.cte_table

* I introduced a new type of RTE, RTE_CTE, which holds a cte_index and
cte_levelsup. This is used to find the CTE that the RTE references.

Weak points:

* It does not change the behavior of recursive queries. That is a little
more complicated, so I wanted to wait for feedback on my patch so far.

* I don't understand set_subquery_pathlist, or that general area of the
code. I made a new set_cte_pathlist, that is basically the same thing,
except I used a hack "dummy_subquery" variable in the RTE to pass along
a pointer to the subquery of the CTE. I think this dummy variable can be
removed, but I just don't understand that part of the code well enough
to know what should happen. And if it does require a subquery at that
point, I'll need to find a way of locating the right cte_table from
inside that function. Any advice here would be appreciated.

* There are a couple of other rough points in places where it's hard to
traverse up the parse tree or query tree.

I can probably work around these weak points, but I wanted to send the
patch to avoid a lot of conflicts or problems later. Tell me whether you
think this is moving in the right direction.

Regards,
Jeff Davis