Jeff Davis <pgsql@j-davis.com> writes:
> Here is a patch that is an initial attempt to reorganize the parse tree
> representation.
Oh dear, we seem to have spent yesterday doing the same work :-(
I'll go over this and try to merge it with my own WIP.
> * There are a couple of other rough points in places where it's hard to
> traverse up the parse tree or query tree.
Yeah, I'd been running into that issue too. Adding an explicit pointer
to the CTE into the RTE doesn't work because it renders the parse tree
un-copiable (at least without something a lot more sophisticated than
copyObject; and saving/loading rule parsetrees would be tough too).
What I've got at the moment is that creation of an RTE_CTE RTE copies
the CTE's lists of output column types/typmods into the RTE. This
eliminates the need for expandRTE and a couple of other places to be
able to find the CTE; everything they need is in the RTE. So far as I
can see, everyplace else that might need to find the CTE from the RTE
is in places that either have a ParseState available, or have some
comparable structure that could provide a way to search upwards for
CTEs (eg, in ruleutils the "deparse context" will need to track
uplevel CTE lists as well as rtables).
It is a bit tedious though. Can anyone think of another way that would
still preserve the notion of multiple RTEs being links to the same CTE
rather than independent subqueries?
regards, tom lane
