Re: Can we let extensions change their dumped catalog schemas?

Поиск
Список
Период
Сортировка
От Jacob Champion
Тема Re: Can we let extensions change their dumped catalog schemas?
Дата
Msg-id 5e5aec8c-a957-4361-6d43-25960ae00386@timescale.com
обсуждение исходный текст
Ответ на Re: Can we let extensions change their dumped catalog schemas?  (Jacob Champion <jchampion@timescale.com>)
Ответы Re: Can we let extensions change their dumped catalog schemas?  (Jacob Champion <jchampion@timescale.com>)
Список 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 по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Decoupling antiwraparound autovacuum from special rules around auto cancellation
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: Progress report of CREATE INDEX for nested partitioned tables