Re: Deprecating RULES - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Deprecating RULES
Date
Msg-id 26613.1350232510@sss.pgh.pa.us
Whole thread Raw
In response to Re: Deprecating RULES  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Deprecating RULES  (Stirling Newberry <stirling.newberry@xigenics.net>)
Re: Deprecating RULES  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
Simon Riggs <simon@2ndquadrant.com> writes:
> On 12 October 2012 19:48, Greg Stark <stark@mit.edu> wrote:
>> On Fri, Oct 12, 2012 at 7:55 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> AFAICS all RULEs can be re-expressed as Triggers or Views.

>> This is a bizarre discussion. Firstly this isn't even close to true.
>> The whole source of people's discontentment is that triggers are *not*
>> equivalent to rules. If they were then they wouldn't be so upset.

> I'm not aware of any rule that can't be rewritten as a trigger or a
> view. Please can anyone show me some examples of those?

Sorry, you're thinking you can put the burden of proof on other people,
but this doesn't work like that.  If you want to deprecate rules on the
grounds that triggers are an adequate substitute, it's up to you to
prove that claim, not for other people to disprove it.

Personally, I don't think I believe it, on both practical and
theoretical grounds:

* Triggers have been available for a very long time, and have been
documented as the better choice for quite a while, but people still try
to use rules.  Whether it's for (admittedly mostly illusory) ease of use
or some other reason, there's some attraction there that we need to
match, not just decree that people can't have it anymore.

* Triggers necessarily operate on a row-at-a-time basis.  In theory,
for at least some bulk operations, a rule could greatly outperform
a trigger.  It's difficult to walk away from that - unless somebody
can prove that the advantage doesn't ever accrue in practice.  But
the fact that a rule won't work in some cases doesn't mean it won't
work for any practical use-case.

* AFTER triggers fall over on sufficiently large updates, since we still
lack any method for spilling the trigger event queue to disk when it
gets too big.  It's fairly difficult to tell people they have to use
triggers as long as that limitation exists and rules don't have it.
(I wonder if this could be alleviated with some sort of "immediate
after" trigger mode that fires after the event is frozen, but without
queueing...)
        regards, tom lane



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: [PATCH] Make pg_basebackup configure and start standby [Review]
Next
From: Boszormenyi Zoltan
Date:
Subject: Re: [PATCH] Make pg_basebackup configure and start standby [Review]