Re: Deprecating RULES - Mailing list pgsql-hackers

From Stirling Newberry
Subject Re: Deprecating RULES
Date
Msg-id 2898ADEE-A8E8-40D3-90A1-C85EA020CEF1@xigenics.net
Whole thread Raw
In response to Re: Deprecating RULES  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Oct 14, 2012, at 12:35 PM, Tom Lane 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 seems there are two somewhat separate issues for discussion, one is the question of what to do about rules, the
secondis deprecation policy in general. Having worked for major software vendors, this are is always a headache.
Considerthe Microsoft, one of the more powerful software vendors of the PC era, is still trying to get people to
upgradeto IE6, but is facing the obstacle of businesses refraining because internally written applications. The
discussionsaround rules and hash indexes going on concurrently on this list share features which would benefit from
havinga 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
thrashup front, but will go a long way to triaging deprecation discussions, and having a work flow in place for when
suchdecisions are made. 





pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Rethinking placement of latch self-pipe initialization
Next
From: Pavel Stehule
Date:
Subject: Re: proposal - assign result of query to psql variable