From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, Tatsuo Ishii <ishii(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Common Table Expressions (WITH RECURSIVE) patch |
Date: | 2008-09-23 13:40:39 |
Message-ID: | 27376.1222177239@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-09-23 13:42:09 | Re: Proposal: move column defaults into pg_attribute along with attacl |
Previous Message | Greg Sabino Mullane | 2008-09-23 13:35:56 | Re: pg_type.h regression? |