> I think the chain of events is that the tiger_data schema is marked as not to be backed up (because it belongs to an extension) and then all of its tables are marked as not to be backed up because they're in a schema that's not to be backed up. The latter > behavior is meant to implement --exclude-schema but it's firing on this case too. I think it might've behaved differently before c42df2d46.
> The whole idea of non-extension objects in a schema owned by an extension seems pretty grotty to me though; that would mean that dropping the extension forces dropping those objects, which I wouldn't think you want. > So I'm not sure it's worth complicating matters to make this case behave differently in pg_dump. > regards, tom lane Ah indeed if I try my pg_dump 9.5beta1 executable it does backup the tables so hasn't always been this way. Are we on the same page, pg_dump should have the same respect for user created data as the extension model does even if ischema is created by the extension? I read your last statement two different ways. Sorry. I was also wrong I can't choose to backup a table from that schema. Not sure what I was doing before, so that's not as inconsistent as I thought. Some more foods for thought: I guess what I find a little confusing is the schema created by the extension to install extension functions/tables etc is not considered part of the extension. For example this postgis_tiger_geocoder is not relocatable. So it installs things in schema called tiger which is automatically created by create extension via extension mechanism. So when I drop the extension the schema is still there. I also can as a user then create tables, functions whatever in tiger schema and those get backed up. So as a user, why would I expect schema tiger_data to be any different from schema tiger that actually holds all tiger installed stuff? I can understand multiple extensions may install things in same schema even if they are not schema relocateable so there is a reason for that, but still it feels a bit odd that we are treating tiger_data differently. I should also add, that if I do put things in tiger_data and then try to drop the extension, the extension refuses to drop without cascade as it should because those objects aren't part of the extension. So why should pg_dump not have the same respect for user created data? Thanks, Regina -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers