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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers