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?
