Re: Deprecating RULES

On Friday, October 12, 2012 01:45:56 AM Peter Geoghegan wrote:
> On 11 October 2012 20:28, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> > Not many RULE-lovers out there, once you've tried to use them.
> >
> > Allowing RULEs complicates various things and can make security more
> > difficult.
>
> What exactly do they make more difficult? Are you particularly
> concerned with the overhead that rules impose when developing certain
> types of features? If so, since there's going to be a legacy
> compatibility mode for a long time, I don't know that deprecating
> rules will buy you much in the next 3 - 4 releases.
>
> > For 9.3, I suggest we create a DDL trigger by default which prevents
> > RULEs and throws an ERROR that explains they are now deprecated.
> >
> > Anybody that really cares can delete this and use them. Sometime in
> > future, we hard code it, barring complaints.
>
> Well, rules have been around since the Berkeley days [1]. I don't
> think that anyone, including Tom, is willing to argue that
> user-defined rules are not a tar-pit (except perhaps ON SELECT DO
> INSTEAD SELECT rules - which are exactly equivalent to views anyway).
> Personally, I'd like to see them removed too. However, in order to be
> able to get behind your proposal, I'd like to see a reasonably
> developed cost/benefit analysis. People do use user-defined rules. For
> example, the xTuple open source ERP package uses ON INSERT DO INSTEAD
> rules [2].
> [2] http://www.xtuple.org/ApiDevelopment
And *drumroll*, they are broken. Every file in
https://postbooks.svn.sourceforge.net/svnroot/postbooks/xtupleserver/trunk/dbscripts/api/views/
seems to have multiple evaluation dangers in the rules.

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