> I think the right approach is to try to complete it so that everyone is
> happy. I will work on this, but unfortunately I don't have a lot of time
> right now, so I can't make any promises.
I think there are two significant bits there:
* Fixing the parsetree representation so that the distinction between
a CTE and an RTE that references the CTE is preserved.
* Implementing some kind of "multiple readout tuplestore" to permit
multiple RTEs to scan a CTE plan without causing any row to be
evaluated more than once.
The first of these seems relatively straightforward: the WITH clause
has to be preserved explicitly in the Query representation, and RTEs
for CTEs should just carry indexes into the WITH list, not copies of
the subqueries. (Hm, we might need both an index and a levelsup
counter, to deal with nested queries...) This would solve ruleutils'
problem, too.
I haven't thought much about the multiple readout tuplestore though.
Anyone have a clear idea how to do that? In particular, can the
existing tuplestore code be enhanced to do it (without sacrificing
performance in the simple case), or do we need something new?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment