Chris Travers <chris.travers@xxxxxxxxx> writes: > On Wed, Sep 28, 2011 at 7:34 AM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: >> I think the true state of affairs is this: rules have a lot of >> surprising behaviors, and if we could think of something that works more >> straightforwardly, we'd love to replace them. > I guess my question is what it would take to eliminate some of the > very surprising behaviors. You're certainly right that unexpected multiple evaluations of volatile expressions is the first thing that bites people. (I don't believe that's restricted to DO ALSO vs INSTEAD though.) I think there are also some fairly serious performance issues for large tables, stemming from the rule system's tendency to create large joins under-the-hood for any rewritten UPDATE or DELETE. Not sure what else. > Instead of considering deprecating and replacing rules with something > else, I guess I am wondering if the issues re fundamental or issues of > implementation. It seems to me we might get more mileage out of > pondering a Rules 2.0 approach, discussing the specifications, etc. > that we would in looking for an alternative. Maybe. The advantage of something-thats-not-a-rule is that it would dodge all issues of backwards compatibility, since we could just leave the rule system behaving as-is until we were ready to remove it altogether. If we try to tweak the semantics of rules then we're likely to break things for people who are using them now. But having said that, it's not unreasonable to think about it and try to scope out exactly what we might tweak. > [ proposal involving a "constant NEW tuple" ] Not sure this specific proposal makes any sense at all. IMO the only real advantage that rules have over triggers is that they work on a set-operation basis not a tuple-by-tuple basis. Don't see how to preserve that characteristic while redefining NEW as a static tuple. (IOW, the example you gave is the least interesting possible case. Think about how an ON INSERT rule would rewrite an INSERT ... SELECT, or in general how you'd rewrite cases that process many tuples.) regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
