Re: Deprecating RULES

On 12 October 2012 00:45, Peter Geoghegan <peter(at)2ndquadrant(dot)com> 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?

Specifically with regard to security, they allow transparent
modification of DML in ways that are not visible to people performing
audits on SQL standard conforming databases. The principle of removing
unused features applies here.

>> 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

AFAICS all RULEs can be re-expressed as Triggers or Views.

Perhaps the right way to do this is to supply a package that allows
appropriate Triggers to be generated from Rule definitions, allowing
us to cope with the few uses out there in the wild. That is more work
and frankly, I don't object to people who use rules, I just object to
new people being told they are useful when they aren't.

As regards cost/benefit analysis, this is a low importance feature,
but then that is why I proposed a low effort fix that is flexible to
the needs of users affected.

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