Re: Deprecating RULES - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Deprecating RULES
Date
Msg-id CAM-w4HOYeoEFKmvf+k3cwCpy9Yg-_YBOQHHhZ6=u6ngC1yG7pw@mail.gmail.com
Whole thread Raw
In response to Re: Deprecating RULES  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Deprecating RULES  (Peter Geoghegan <peter@2ndquadrant.com>)
Re: Deprecating RULES  (Josh Berkus <josh@agliodbs.com>)
Re: Deprecating RULES  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Deprecating RULES  ("Joshua D. Drake" <jd@commandprompt.com>)
Re: Deprecating RULES  (Simon Riggs <simon@2ndQuadrant.com>)
Re: Deprecating RULES  (John R Pierce <pierce@hogranch.com>)
List pgsql-hackers
I dislike both of the explanations above which don't actually explain
why people shouldn't use rules (Josh does say they're tricky which is
a start). Just telling people we hate parts of the system doesn't
really come off well and leaves them wondering why.

I would suggest something like

Warning: RULES are tricky to use correctly. They rewrite the original
query into a new query before it is run and it is very hard to
correctly anticipate and rewrite every possible input query into the
desired result. There are also unexpected interactions with other
components when RULES do something unexpected such as rewrite a single
query to return two result sets.

For most applications it's much simpler and more predictable to use
TRIGGERs. ROW level triggers are evaluated for each row the original
query is about to process (or has just finished processing) and this
makes them much easier to follow. Statement level TRIGGERs can be used
for audit logs and similar operations which need to run once per
statement.



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Deprecating RULES
Next
From: Andrew Dunstan
Date:
Subject: Re: Deprecating RULES