Jeff Davis <[EMAIL PROTECTED]> writes: > 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