Re: Extensions not dumped when --schema is used

Le mer. 20 mai 2020 à 16:39, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> a écrit :

> Guillaume Lelarge <guillaume(at)lelarge(dot)info> writes:
> > Le mer. 20 mai 2020 à 11:26, Daniel Gustafsson <daniel(at)yesql(dot)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.