Guillaume Lelarge <guillaume@lelarge.info> writes: > Le mer. 20 mai 2020 à 11:26, Daniel Gustafsson <daniel@yesql.se> a écrit : >> The question is what --extensions should do: only dump any >> extensions that objects in the schema depend on; require a pattern and only >> dump matching extensions; dump all extensions (probably not) or something >> else?
> Actually, "dump all extensions" (#3) would make sense to me, and has my > vote.
I think that makes no sense at all. By definition, a dump that's been restricted with --schema, --table, or any similar switch is incomplete and may not restore on its own. Typical examples include foreign key references to tables in other schemas, views using functions in other schemas, etc etc. I see no reason for extension dependencies to be treated differently from those cases.
Agreed.
In any use of selective dump, it's the user's job to select a set of objects that she wants dumped (or restored). Trying to second-guess that is mostly going to make the feature less usable for power-user cases.
Agreed, though right now he has no way to do this for extensions.
As a counterexample, what if you want the dump to be restorable on a system that doesn't have all of the extensions available on the source? You carefully pick out the tables that you need, which don't require the unavailable extensions ... and then pg_dump decides you don't know what you're doing and includes all the problematic extensions anyway.
That's true.
I could get behind an "--extensions=PATTERN" switch to allow selective addition of extensions to a selective dump, but I don't want to see us overruling the user's choices about what to dump.
With all your comments, I can only agree to your views. I'll try to work on this anytime soon.