Le mer. 20 mai 2020 à 16:39, Tom Lane <t...@sss.pgh.pa.us> a écrit :
> Guillaume Lelarge <guilla...@lelarge.info> writes: > > Le mer. 20 mai 2020 à 11:26, Daniel Gustafsson <dan...@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. -- Guillaume.
