Dean Rasheed <dean.a.rash...@gmail.com> writes:
> If we did nothing here then it would go on to either fire any INSTEAD
> OF triggers or raise an error if there aren't any. The problem with
> that is that it makes trigger-updatable views and auto-updatable views
> inconsistent in their behaviour with qualified INSTEAD rules. I don't
> think the existing interaction between trigger-updatable views and
> qualified INSTEAD rules is documented, so perhaps that's something
> that needs work.
I'm still unhappy about this decision though, and after further thought
I think I can explain why a bit better: it's actually *not* like the way
rules work now. The current rule semantics are basically that:
1. The original query is done only if there are no unconditional INSTEAD
rules and no conditional INSTEAD rule's condition is true.
2. Unconditional INSTEAD actions are done, well, unconditionally.
3. Each conditional INSTEAD action is done if its condition is true.
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. Which would mean that it happens
unconditionally, per #2. As submitted, though, the auto-update query
executes only if there are no unconditional INSTEAD rules *and* no
conditional INSTEAD rule's condition is true. I do not think this is
either consistent or useful. It's treating the auto-update replacement
query as if it were the original, which it is not.
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
