On Sat, Mar 2, 2013 at 3:06 PM, Kevin Grittner <kgri...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
