Re: Deprecating RULES
От | Peter Geoghegan |
---|---|
Тема | Re: Deprecating RULES |
Дата | |
Msg-id | CAEYLb_WiVzEgsN2wypQsJQSw5EiY1fQ_RSQhD34jkc2mhNYMhg@mail.gmail.com обсуждение исходный текст |
Ответ на | Deprecating RULES (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Deprecating RULES
Re: Deprecating RULES |
Список | pgsql-hackers |
On 11 October 2012 20:28, Simon Riggs <simon@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]. [1] http://db.cs.berkeley.edu/papers/ERL-M89-82.pdf [2] http://www.xtuple.org/ApiDevelopment -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services
В списке pgsql-hackers по дате отправления: