Dean Rasheed <dean.a.rash...@gmail.com> writes:
> On 8 November 2012 17:37, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> I believe that the right way to think about the auto-update
>> transformation is that it should act like a supplied-by-default
>> unconditional INSTEAD rule.
> But if you treat the auto-update transformation as a
> supplied-by-default unconditional INSTEAD rule, and the user defines
> their own conditional INSTEAD rule, if the condition is true it would
> execute both the conditional rule action and the auto-update action,
> making it an ALSO rule rather than the INSTEAD rule the user
> specified.
Well, that's how things work if you specify both a conditional and an
unconditional INSTEAD action, so I don't find this so surprising.
What you're arguing for would make some sense if the auto-update feature
could be seen as something that acts ahead of, and independently of,
INSTEAD rules and triggers. But it can't be treated that way: in
particular, the fact that it doesn't fire when there's an INSTEAD
trigger pretty much breaks the fiction that it's an independent
feature. I would rather be able to explain its interaction with rules
by saying "it's a default implementation of an INSTEAD rule" than by
saying "well, it has these weird interactions with INSTEAD rules, which
are different for conditional and unconditional INSTEAD rules".
Or we could go back to what I suggested to start with, which is that the
auto-update transformation doesn't fire if there are *either*
conditional or unconditional INSTEAD rules. That still seems like the
best way if you want an arms-length definition of behavior; it means we
can explain the interaction with INSTEAD rules exactly the same as the
interaction with INSTEAD triggers, ie, having one prevents the
transformation from being used.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
