Re: Deprecating RULES

From: Stirling Newberry <stirling(dot)newberry(at)xigenics(dot)net>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Deprecating RULES
Date: 2012-10-14 18:49:50
Message-ID: 2898ADEE-A8E8-40D3-90A1-C85EA020CEF1@xigenics.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Oct 14, 2012, at 12:35 PM, Tom Lane wrote:

> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
>> On 12 October 2012 19:48, Greg Stark <stark(at)mit(dot)edu> wrote:
>>> On Fri, Oct 12, 2012 at 7:55 AM, Simon Riggs <simon(at)2ndquadrant(dot)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 seems there are two somewhat separate issues for discussion, one is the question of what to do about rules, the second is deprecation policy in general. Having worked for major software vendors, this are is always a headache. Consider the Microsoft, one of the more powerful software vendors of the PC era, is still trying to get people to upgrade to IE6, but is facing the obstacle of businesses refraining because internally written applications. The discussions around rules and hash indexes going on concurrently on this list share features which would benefit from having a general policy discussion abstracted from the attachments or dislikes of particular features.

I would suggest that a thread be spawned off to consider deprecation policy, including substantive reasons for deprecation, the burden of proof on those proposing deprecation, means of communicating to users. This will cause some thrash up front, but will go a long way to triaging deprecation discussions, and having a work flow in place for when such decisions are made.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Boszormenyi Zoltan 2012-10-14 20:23:48 Re: [PATCH] Make pg_basebackup configure and start standby [Review]
Previous Message Peter Geoghegan 2012-10-14 18:45:31 Re: Rethinking placement of latch self-pipe initialization