Re: Common Table Expressions (WITH RECURSIVE) patch - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Common Table Expressions (WITH RECURSIVE) patch
Date
Msg-id 27376.1222177239@sss.pgh.pa.us
Whole thread Raw
In response to Re: Common Table Expressions (WITH RECURSIVE) patch  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers
Gregory Stark <stark@enterprisedb.com> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> 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).

> Well the alternative to direct pointers is as you did with subqueries, turning
> the set into a flat array and storing indexes into the array. I'm not sure if
> that applies here or not.

I think that just changes the problem into "where can I find the array?" ...

The real issue here is that simplicity of copying etc requires that
child nodes in a parse tree never have back-links leading up to their
parent.  If we were willing to drop that requirement for Query then
we'd not need any auxiliary data structures to chase up to upper-level
rtables or CTEs.  I'm not sure this cure is better than the disease
though.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Greg Sabino Mullane"
Date:
Subject: Re: pg_type.h regression?
Next
From: Tom Lane
Date:
Subject: Re: Proposal: move column defaults into pg_attribute along with attacl