On Friday, October 12, 2012 01:45:56 AM Peter Geoghegan wrote: > On 11 October 2012 20:28, Simon Riggs <si...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
