Re: Deprecating RULES - Mailing list pgsql-hackers

On 14 October 2012 17:35, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

It's fair comment that if one thing can replace another, the burden of
proof is on the claimant.

But I'm not just saying rules should be deprecated because they are
superfluous. Rules are broken in various ways that can cause data
corruption, security issues and user unhappiness. Those downsides
outweigh the few possible advantages.

We have no theoretical model that describes how they should behave and
it would seem nobody cares. The reality is that rules aren't going to
be fixed and I think we should admit that and put rules to rest.
Stonebraker has moved on, and so should we, from his bad ideas.

> 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.

I agree there is a huge initial attraction, just an equally huge
disappointment later. I used to quite like them myself, once.


> * 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.

The absence of COPY support makes any use case of rules moot for bulk
data cases, IMHO.

It's possible rules are good for something and almost impossible for
me to prove that's not true.

> * 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...)

I think we need that mode for RI anyway, to allow us to optimize cases
that repeatedly perform the same action, such as fk locks against a
small reference table. Not sure if that is instead of or as well as
scroll to disk.

I don't think rules solve those problems well enough to be a genuine
substitute. I think people just turn RI off and run checks offline.


Why say this all now? No reason, apart from never seems to be the
wrong answer. Apart from docs, I'll desist.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services