From: | Guillaume Lelarge <guillaume(at)lelarge(dot)info> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Extensions not dumped when --schema is used |
Date: | 2021-01-25 13:34:02 |
Message-ID: | CAECtzeVNstzUb6ft8=dmtV5XUQ-PdLWriG4yVqpgeVM0Qo0e4g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
Le sam. 23 mai 2020 à 14:53, Guillaume Lelarge <guillaume(at)lelarge(dot)info> a
écrit :
> 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.
>
>
"Anytime soon" was a long long time ago, and I eventually completely forgot
this, sorry. As nobody worked on it yet, I took a shot at it. See attached
patch.
I don't know if I should add this right away in the commit fest app. If
yes, I guess it should go on the next commit fest (2021-03), right?
--
Guillaume.
Attachment | Content-Type | Size |
---|---|---|
dump_extensions_v1.patch | text/x-patch | 7.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2021-01-25 13:35:02 | Re: New IndexAM API controlling index vacuum strategies |
Previous Message | Konstantin Knizhnik | 2021-01-25 13:27:25 | Re: Columns correlation and adaptive query optimization |