Re: Can we let extensions change their dumped catalog schemas? - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: Can we let extensions change their dumped catalog schemas?
Date
Msg-id 5e5aec8c-a957-4361-6d43-25960ae00386@timescale.com
Whole thread Raw
In response to Re: Can we let extensions change their dumped catalog schemas?  (Jacob Champion <jchampion@timescale.com>)
Responses Re: Can we let extensions change their dumped catalog schemas?
List pgsql-hackers
On 1/12/23 11:04, Jacob Champion wrote:
> On Wed, Jan 11, 2023 at 1:03 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Jacob Champion <jchampion@timescale.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



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Decoupling antiwraparound autovacuum from special rules around auto cancellation
Next
From: Tomas Vondra
Date:
Subject: Re: Progress report of CREATE INDEX for nested partitioned tables