Andrew,
> 1) any reference in an insert rule to NEW.col where col has a volatile
> default, or the expression in the insert statement was volatile, or
> the expression's value is changed by the insert, will do the wrong
> thing:
Is this different from triggers?
> 2) any rule with multiple actions, each action is affected by the results of
> the previous ones. A classic example of this is in the use of OLD in
> delete or update rules; OLD _does not return a row_ if a previous action
> in the rule deleted the row or updated it so that it no longer matches.
I know this is not any different from triggers which cascade.
David's basic proposal, as I understand, is to remove RULEs and replace
them with triggers on views. However, there are *lots* of ways to screw
yourself up with triggers as well. For example see my previously
reported bug about referential integrity and self-triggers. Triggers
also have potential security issues which rules lack.
So while rules are hard to use and easy to mess up, so are triggers. So
while an (arguable) problem is being pointed out, no real solution is
being proposed.
With some irony, this discussion came about starting with the writable
CTE patch ... which is a truly massive foot-gun for someone who doesn't
know how to write CTEs. Huge opportunities there for a new DBA to
either lock up the server or overwrite half their database. Does that
mean we shouldn't do them? No.
I happen to like having RULEs in my arsenal of tricks for getting the
database to do Nifty Stuff. I've always considered them advanced
database programming, and not for beginners. But that describes a lot
of PostgreSQL functionality: security definer functions, run-time DDL
generation, SQL/MED, untrusted languages, user-defined types and
operators. But it's these advanced features which are what makes
PostgreSQL interesting as a database.
--Josh Berkus