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

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-03-08 21:39:18
Message-ID: CAAWbhmgcfcaCSjCjN1EyLJbhAHsFCeqYnnOTiZO2PBi+ThhU9Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Feb 7, 2023 at 10:16 AM Jacob Champion <jchampion(at)timescale(dot)com> wrote:
> Even more concretely, here's a draft patch. There's no nuance --
> setting dump_version affects all past versions of the extension, and
> it can't be turned off at restore time. So extensions opting in would
> have to be written to be side-by-side installable. (Ours is, in its
> own way, but the PGDG installers don't allow it -- which maybe
> highlights a weakness in this approach.) I'm still not sure if this
> addresses Tom's concerns, or just adds new ones.

Any general thoughts on this approach? I don't think it's baked enough
for registration yet, but I also don't know what approach would be
better.

Given the recent chatter around extension versions in other threads
[1, 2], I feel like there is a big gap between the Postgres core
expectations and what extension authors are actually doing when it
comes to handling version upgrades. I'd like to chip away at that,
somehow.

Thanks,
--Jacob

[1] https://www.postgresql.org/message-id/212074.1678301349%40sss.pgh.pa.us
[2] https://www.postgresql.org/message-id/CA%2BTgmoYqK6nfP15SjuyO6t5jOmymG%3DqO7JOOVJdTOj96L0XJ1Q%40mail.gmail.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2023-03-08 21:40:05 Re: SQL/JSON revisited
Previous Message Nathan Bossart 2023-03-08 21:38:38 Re: Get rid of PgStat_BackendFunctionEntry