Re: pg_dump does not refresh matviews from extensions

Jim,

* Jim Nasby (Jim(dot)Nasby(at)BlueTreble(dot)com) wrote:
> I think $SUBJECT is a bug. While it would be unusual for an
> extension to have a matview, it's still allowed, and as it stands
> right now that view won't be refreshed at the end of a restore,
> unlike other matviews.
>
> I started looking into a patch for this, but I'm not sure of the
> best way to handle it. One possibility is to glom this in with the
> code that handles extension config tables, but that doesn't feel
> right since matviews aren't really config.
>
> Would the best option be to change selectDumpableTable(), but I
> suspect that'd have to use the same "dumpobj" logic that
> processExtensionTables() uses.

As I noted elsewhere, I'd kind of like to see processExtensionTables()
go away in favor of doing more in selectDumpableTable(), since we can
now track the fact that we should restore just the data for a given
table through the dump bitmap.

As for $SUBJECT, I feel like it really depends, doesn't it? If the
extension creates the matview w/ no data in it, and doesn't mark it as a
config table, should we really refresh it? On the other hand, if the
extension creates the matview and either refreshes it, or something
else refreshes it later, then perhaps we should do so too, to get us
back to the same state.

Of course, we also need to consider pg_upgrade and make sure that,
whatever we do, what happens with pg_upgrade makes sense.

Thanks!

Stephen