Re: Delete rule does not prevent truncate

On 07/24/2015 02:24 AM, Tim Smith wrote:
>>
>> Just in case it has not been made obvious yet, rules are silently
>> deprecated. They still exist because views depend on them, but it is
>> generally considered best practices to not use them outside that realm.
>
>
> Well, the manual doesn't seem to reflect that fact.
>
> If that's how the developers feel about rules, i.e they can't be
> bothered to make any changes to the rules code any more, no matter how
> minor (e.g. this TRUNCATE issue), then you should explicitly state in
> the manual that they are depreciated, and stop making stupid
> statements like "so if many rows are affected in one statement, a rule
> issuing one extra command is likely to be faster than a trigger" that
> encourage people to use rules !
>

Seems that section needs editing to make it clearer that this depends on
what type of trigger you use. Or as it states here:

http://www.postgresql.org/docs/9.4/interactive/sql-createtrigger.html
"
A trigger that is marked FOR EACH ROW is called once for every row that
the operation modifies. For example, a DELETE that affects 10 rows will
cause any ON DELETE triggers on the target relation to be called 10
separate times, once for each deleted row. In contrast, a trigger that
is marked FOR EACH STATEMENT only executes once for any given operation,
regardless of how many rows it modifies (in particular, an operation
that modifies zero rows will still result in the execution of any
applicable FOR EACH STATEMENT triggers).
"

At any rate you know what the situation is. Getting increasingly
belligerent is not going to help that situation and the energy would
seem to me better spent on adapting to reality and moving on.

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com