Re: [HACKERS] pg_dump does not refresh matviews from extensions
On Thu, Feb 23, 2017 at 5:11 AM, Jim Nasby wrote: > Now that I know that, I guess I'm kinda on the fence about doing it > automatically, because AFAIK there'd be no way to override that automatic > behavior. I can't really conceive of any reason you wouldn't want the > refresh, but since it's not happening today... Well, it would make pg_dump run longer to do something you may not care about. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_dump does not refresh matviews from extensions
On 2/21/17 2:05 PM, Stephen Frost wrote: 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. I didn't think to test marking the matview as dumpable. If I do that then a refresh item does get created, and it's actually based on whether the view contains any data. We should at least document that. Now that I know that, I guess I'm kinda on the fence about doing it automatically, because AFAIK there'd be no way to override that automatic behavior. I can't really conceive of any reason you wouldn't want the refresh, but since it's not happening today... -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_dump does not refresh matviews from extensions
Jim, * Jim Nasby (jim.na...@bluetreble.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 signature.asc Description: Digital signature