> -----Original Message----- > From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers- > ow...@postgresql.org] On Behalf Of Simon Riggs > Sent: Sunday, October 14, 2012 5:30 PM > To: Tom Lane > Cc: Greg Stark; Peter Geoghegan; PostgreSQL-development > Subject: Re: [HACKERS] Deprecating RULES > > On 14 October 2012 17:35, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Simon Riggs <si...@2ndquadrant.com> writes: > >> On 12 October 2012 19:48, Greg Stark <st...@mit.edu> wrote: > >>> On Fri, Oct 12, 2012 at 7:55 AM, Simon Riggs <si...@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's fair comment that if one thing can replace another, the burden of proof is > on the claimant. > > But I'm not just saying rules should be deprecated because they are > superfluous. Rules are broken in various ways that can cause data corruption, > security issues and user unhappiness. Those downsides outweigh the few > possible advantages.
If we rely on people that dislike RULEs to provide examples of where RULEs necessary then through simple ignorance we are likely to deduce that RULEs are of no practical use. People who use rules because there are no viable alternatives need to elaborate on the how and why RULEs are used so that the ignorant can become educated and maybe even provide current or future alternatives to using RULEs. It does seem that considerable documentation work needs to be done regardless of whether a final decision to deprecate is made. Furthermore, the results of that documentation process will provide valuable insight toward that decision. This thread should probably end and a new one discussing the design and content of said documentation should probably be started. As I do not have a concrete idea of how that process would look with respect to this community I'll leave the initial posting to someone with more intimate knowledge of the community dynamics. David J. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
