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?
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
