On Thu, Jul 23, 2015 at 12:57:20PM +0100, Tim Smith wrote: > It is important to realize that a rule is really a command transformation > mechanism, or command macro. The transformation happens before the > execution of the command starts. If you actually want an operation that > fires independently for each physical row, you probably want to use a > trigger, not a rule
Well, yes, but the discussion of the rules system in earlier manuals was actually, I thought, somewhat more detailed; and it outlined what rules really did, which was alter the command at the parse tree. That's what I think the above is saying also, but it may not be quite as plain. So it's rather more like a statement-level trigger. > Thus, I should not have to use a trigger for TRUNCATE because the "each > row" concept does not apply. Plus it makes perfect sense to want to > transform the truncate command and transform into ignore Well, yes, but really in this case you want a per-statement trigger, and there's not the same distinction in rules, either. I can't believe that people would reject a patch (though you should ask on -hackers, not here); but you asked what was behind the design decision and I told you. But in general, the experience seems to be that triggers are easier to get right (novice or no, _pace_ section 38.7). Best regards, A -- Andrew Sullivan a...@crankycanuck.ca -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
