Skip site navigation (1) Skip section navigation (2)

Re: BUG #6051: wCTE query fail with wrong error text on a table with rules

From: David Fetter <david(at)fetter(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>,"Jehan-Guillaume (ioguix) de Rorthais" <jgdr(at)dalibo(dot)com>,pgsql-bugs(at)postgresql(dot)org,Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>
Subject: Re: BUG #6051: wCTE query fail with wrong error text on a table with rules
Date: 2011-06-06 16:41:01
Message-ID: 20110606164101.GA25901@fetter.org (view raw or flat)
Thread:
Lists: pgsql-bugs
On Sat, Jun 04, 2011 at 05:24:22PM -0400, Tom Lane wrote:
> Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
> > On Fri, Jun 3, 2011 at 10:42 AM, Jehan-Guillaume (ioguix) de Rorthais
> > <jgdr(at)dalibo(dot)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 <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david(dot)fetter(at)gmail(dot)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

In response to

Responses

pgsql-bugs by date

Next:From: Robert HaasDate: 2011-06-07 02:29:02
Subject: Re: BUG #6041: Unlogged table was created bad in slave node
Previous:From: Matthijs BomhoffDate: 2011-06-06 14:54:26
Subject: Re: MACADDR parsing issues

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group