David Fetter <da...@fetter.org> writes:
> On Sat, Jun 04, 2011 at 05:24:22PM -0400, Tom Lane wrote:
>> We could paste a copy of the original's cteList into the rule action,
>> but there are still issues:
>>
>> * If there's more than one rule action, we could end up executing
>> multiple copies of the same CTE query; which breaks the expectation
>> of single evaluation for a CTE.
>>
>> * If there are CTEs attached to the rule action, as well as to the
>> original query, and there is a conflict of CTE names between them,
>> we can't handle that AFAICS. (The planner expects to look up entries
>> in a cteList by name...)
>>
>> * Maybe some other things that aren't obvious yet.
>>
>> I don't particularly mind throwing a not-implemented error for the first
>> case (ie, just say multiple rule actions don't mix with CTE queries);
> Great :)
>> but the second case seems seriously annoying, since there's no way
>> for someone to write a CTE-containing rule action without risking a
>> conflict. Ideas anybody?
> Is there some way to throw "not implemented" there, too? It seems to
> me that making accommodations for the user-modifiable part of our
> rewrite rules isn't the right direction to go, as we're well on our
> way to phasing the user-modifiable part out.
Yes, we certainly can throw an error for that, it's just going to be a
pain from a usability standpoint. But I agree that the number of people
affected might be small, so it's not worth doing a significant rewrite
for right now.
I've committed a patch along these lines.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
