Re: Deprecating RULES - Mailing list pgsql-hackers

On 10/17/2012 03:06 PM, Daniel Farina wrote:
> On Wed, Oct 17, 2012 at 10:50 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
>>>> 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.
>> People can keep ignoring that if they like, but some of us won't. This
>> mantra of "there is no reason at all to use rules" is like climate change
>> denial - no matter how many times you say it that won't make it true.
> I think there is an assumed presumption on behalf of those those
> vigorously opposing the deprecation of rules that everyone understands
> what the use cases for rules are and their respective commonality.  So
> far, the discussion has been pretty unenlightening to me, and I find
> the notion that those in favor of deprecation are just skirting well
> known questions ill justified.  Just because an "in theory..." case
> works better is not in and of itself enough to warrant a vigorous
> defense -- perhaps I missed the email where people said "yes, I see
> that all the time when rules are involved and wouldn't want to go
> without it".
>
> You and Josh seem to be strong proponents of rules for reasons other
> than "I just don't want to break applications".  That's not too many
> to ask both of you: can you itemize your use cases and how important
> you feel they are?
>
> I'll cost-size it for you: for me, as of my current understanding, if
> but one more defect can be removed per year by dropping all
> maintenance of RULES in exchange, I'd take that trade, as I understand
> things right now.
>


I'll give you one case, although I still think Tom is right - the onus 
of proof is on those proposing to remove a feature, not the other way 
around.

Some years ago I was partitioning a large data store. By far the fastest 
way to do this, by about an order of magnitude, turned out to be using a 
partitioning rule. In testing it was way faster than using a trigger, 
even one written in C, or pulling out the individual partitions one by 
one. And I don't thing writing triggers in C is an acceptable 
replacement for rules anyway.

One I had the data partitioned I dropped the rule and put a trigger in 
place.

Now I'd be fairly miffed if we just removed that capability. I 
personally feel that the bar for removing features should be pretty darn 
high.

cheers

andrew