On Sat, Mar 2, 2013 at 3:06 PM, Kevin Grittner <kgrittn@ymail.com> wrote:
>
> (1) Any DML against the MV would need to be limited to some
> context fired by the underlying changes. If we allow changes to
> the MV outside of that without it being part of some "updateable
> MV" feature (reversing the direction of flow of changes), the MV
> could not be trusted at all. If you're going to do that, just use
> a table.
Oh! I misunderstood what you were suggesting. I think we were talking
at cross-purposes.
You're imagining a user issues truncate against the underlying
table(s) and the code that handles updating the materialized view will
need to issue a truncate against the MV to update it.
I was imagining that you wanted to be able to issue DML against the MV
just as one can against an updateable view. That DML should propagate
to the underlying table(s) through various magic.
It's a pretty theoretical fear now but one day it may be important to
avoid confusion between these two.
--
greg
