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
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 |