Consider the following scenario:
create table t1 as select 1 as x;
create materialized view mv1 as select * from t1;
create materialized view mv2 as select * from mv1;
create materialized view mv3 as select * from mv2;
refresh materialized view mv1 with no data;
This state is not dumpable by pg_dump, because there's no way to REFRESH
mv2 or mv3 as long as mv1 hasn't been populated. (Well, I suppose we
could REFRESH mv1, then mv2, then mv3, then mv1 again WITH NO DATA; but
do we really want to do that? pg_dump is certainly unable to do such
a thing today, anyway.)
Currently, what pg_dump does about this is to silently suppress the
REFRESH commands for mv2 and mv3. Well, that's nice in terms of not
having a dump script that fails, but I'm not sure it meets the principle
of least astonishment.
Now, this is only an issue if you assume that pg_dump's charter is to
reproduce exactly the set of populated/non-populated MV states in the
source database. Considering that it has little hope of exactly
reproducing their contents, I'm not sure that that charter makes much
sense anyway.
I've thought for some time that, given that it can't reproduce the MV
states exactly, pg_dump shouldn't even try. I think it would be more
useful to have two operating modes selectable by command line switch:
refresh all matviews, or refresh none of them.
Or maybe there's some other better way to approach it.
Thoughts?
regards, tom lane
