> 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?
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: