From: | Jacob Champion <jchampion(at)timescale(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Can we let extensions change their dumped catalog schemas? |
Date: | 2023-01-17 23:18:26 |
Message-ID: | 5e5aec8c-a957-4361-6d43-25960ae00386@timescale.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 1/12/23 11:04, Jacob Champion wrote:
> On Wed, Jan 11, 2023 at 1:03 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Jacob Champion <jchampion(at)timescale(dot)com> writes:
>>> Right, I think it would have to be opt-in. Say, a new control file
>>> option dump_version or some such.
>>
>> That would require all the installed extensions to cope with this
>> the same way, which does not seem like a great assumption.
>
> How so? Most installed extensions would not opt into a version dump,
> I'd imagine.
As a concrete example, Timescale's extension control file could look
like this:
default_version = '2.x.y'
module_pathname = '$libdir/timescaledb-2.x.y'
...
dump_version = true
which would then cause pg_dump to issue a VERSION for its CREATE
EXTENSION line. Other extensions would remain with the default
(dump_version = false), so they'd be dumped without an explicit VERSION.
(And in the case of option 3, the name of the control file option
changes -- dump_internals, maybe? -- but it still doesn't affect other
installed extensions.)
--Jacob
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2023-01-18 00:04:06 | Re: Progress report of CREATE INDEX for nested partitioned tables |
Previous Message | Peter Geoghegan | 2023-01-17 22:56:16 | Re: Decoupling antiwraparound autovacuum from special rules around auto cancellation |