Andrew,
From the manual:
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
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
On Thursday, 23 July 2015, Andrew Sullivan <
ajs@crankycanuck.ca> wrote:
On Thu, Jul 23, 2015 at 08:06:19AM +0100, Tim Smith wrote:
> What exactly is was the design decision that lead to TRUNCATE being
> supported by triggers but not by rules ?
There are two things. First, probably the design decision was, "I
care about triggers." TRUNCATE was added (I believe) in version 7.0,
and even then there was some caution indicated about the use of rules.
See for instance
http://www.postgresql.org/docs/7.0/static/rules19784.htm. So you
might be partly right.
But second, it isn't clear what it would mean for TRUNCATE to be
supported by rules. Rules do query parse tree rewriting. That is,
they rewrite the query on the way through the system before they can
possibly have any effect, changing one SQL statement into
(effectively) a different one by the time it executes. There is only
one possible effect from TRUNCATE, and that is to eliminate all the
data in the table. I don't know what rewriting such a query would
mean.
Best regards,
A
--
Andrew Sullivan
ajs@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