From: | Andrew Sullivan <ajs(at)crankycanuck(dot)ca> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Delete rule does not prevent truncate |
Date: | 2015-07-23 12:29:31 |
Message-ID: | 20150723122930.GI9120@crankycanuck.ca |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
ajs(at)crankycanuck(dot)ca
From | Date | Subject | |
---|---|---|---|
Next Message | Devrim GÜNDÜZ | 2015-07-23 12:36:49 | Re: plv8 package in PostgreSQL 9.4 Yum repositories |
Previous Message | Tim Smith | 2015-07-23 11:57:20 | Re: Delete rule does not prevent truncate |