On Sat, Jun 04, 2011 at 05:24:22PM -0400, Tom Lane wrote: > Merlin Moncure <mmonc...@gmail.com> writes: > > On Fri, Jun 3, 2011 at 10:42 AM, Jehan-Guillaume (ioguix) de Rorthais > > <j...@dalibo.com> wrote: > >> test=# CREATE RULE test_ins AS ON INSERT TO test DO INSTEAD INSERT INTO > >> test2 VALUES (NEW.i); > >> CREATE RULE > >> test=# WITH t1 AS ( > >> DELETE FROM ONLY test RETURNING * > >> ) > >> INSERT INTO test SELECT * FROM t1; > >> ERROR: could not find CTE "t1" > > > IIRC the fact that rules don't play nice with wCTE was brought up > > several times during the implementation discussions. I'm not saying > > the error message is great, but you can pretty much add this to the > > giant pile of reasons not to use rules at all (particularly in 9.1 > > with the view triggers). > > There are definitely cases that don't work, but I had thought we at > least threw an intelligible "not implemented" error for all of them. > This one seems to be an oversight: specifically, rewriteRuleAction() > isn't considering the possibility that the rewritten rule action will > need to make use of CTEs from the original query. > > 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. Cheers, David. -- David Fetter <da...@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs