2010/7/13 Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>:
> On 7/12/10 9:34 PM +0300, Tom Lane wrote:
>>
>> Marko Tiikkaja<marko.tiikkaja@cs.helsinki.fi> writes:
>>>
>>> ... So what I'm now thinking of is making the planner plan that as a
>>> single
>>> Query, and make the planner expand it into multiple PlannedStmts if
>>> necessary. This would break the existing planner hooks, but I don't
>>> think that's a huge problem. Does anyone see any obvious flaws in this?
>>
>> How will that interact with the existing rewriter? It sounds a lot
>> like a recipe for duplicating functionality ...
>
> I was thinking that the rewriter would look at the top-level CTEs and
> rewrite all non-SELECT queries into a list of Queries and store that list
> into the CommonTableExprs. The planner would then use this information and
> also expand the rewrite products.
Why didn't you choose this strategy? ISTM changing signature of
planner() and standard_planner() makes it more difficult to commit
this feature unnecessarily.
I thought at first that it is possible and better to split the
statement into multiple Querys in the rewriter and pass them to the
planner, but as you mentioned they should collaborate each other like
in ctelevelsup, so to pass a single Query to the planner is probably
the answer. However, you can store the sub (ie, in WITH clause)
PlannedStmt in the top level PlannedStmt and extract the sub
statements in pg_plan_queries() or anywhere in the PortalXXX() then
add them to the execution list.
Regards,
--
Hitoshi Harada
