Re: Delete rule chain stops unexpectedly

Tom Lane wrote:
>>A quote from the postgresql manual:
> 
>>"But for ON UPDATE and ON DELETE rules, the original query is done after the 
>>actions added by rules. This ensures that the actions can see the to-be-updated 
>>or to-be-deleted rows"
> 
> Yes, I know that quote.  I wrote it.  It's not relevant here because the
> original query (the delete against the view) is never done at all, since
> you have a DO INSTEAD rule.  What is relevant is the timing of the
> delete issued against the underlying table, and you have that scheduled
> to occur too early because the rule that does it is first in
> alphabetical order.

Oh yeah, whoops, I was under a false impression of what the original query was...

> Because the rule converts those inserts into, effectively,
> 
>     INSERT INTO debuglog SELECT ... WHERE EXISTS(some matching OLD row);
> 
> and there are no longer any matching OLD rows in the view.  (If it
> didn't act that way then the INSERTs would execute even for a "DELETE
> WHERE false".  If you find any of this surprising or not what you want,
> you should probably be using triggers not rules.)

Ah, I see. I'll convert them to triggers, or just put the delete at the end. I 
could even put all this in one rule, that would be easier.

> 
> 
>>Or, that all the rules _are_
>>executed when I call the query with "explain analayze".
> 
> 
> Hmm ... this appears to be a bug in EXPLAIN ANALYZE: it really should
> bump the CommandCounter between plan trees, but fails to ...

Is this something I have to report?