Chris Travers <chris.travers@gmail.com> writes:
> On Wed, Sep 28, 2011 at 7:34 AM, Tom Lane <tgl@sss.pgh.pa.us> 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
