So I have basic non-recursive queries working. However currently it's essentially inlining the subquery at every call-site which obvious will never handle recursive queries and in fact doesn't even do what people expect from the basic syntax. The use case for the WITH syntax is when you have an expensive query you want to avoid calling multiple times from within your query.
postgres=# with frotz(a) as (select * from x) select * from frotz,frotz as x(b); a | b ---+--- 1 | 1 1 | 2 2 | 1 2 | 2 (4 rows) "Tom Lane" <[EMAIL PROTECTED]> writes: > Gregory Stark <[EMAIL PROTECTED]> writes: >> Is it ok to scribble on and reuse objects from the parse tree when generating >> the transformed tree? Or should the transformed query object be built from >> freshly allocated nodes? > > We do both already; take your pick. If you do the former, though, > I suggest designing the code so that it's a no-op on an > already-transformed node. It used to be the case that the grammar > could generate multiple references to the same subtree (e.g., by > transforming "x BETWEEN y AND z" to "x >= y AND x <= z") and I'm not > sure we have removed all such shortcuts. I was wondering whether it was necessary to copy the alias node from an existing node or if I could just create more references to it. > There's some logical cleaniness to using different node types for raw > and transformed trees, but when there's a simple one-for-one > correspondence this is probably overkill. Currently I'm storing a lit of RangeSubselects in the pstate. That just happened to be a node with an alias and a subquery which is what I needed. I was considering replacing the SelectStmt node with a Query node directly instead of creating a new RangeSubselect node. However now I'm thinking I probably need to do something more complicated. As it is there's no way to tell when I add a rangetable to a query that it came from a subquery in the common table expression list in the pstate instead of from an inlined subquery. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org