Re: [PATCH] Support % wildcard in extension upgrade filenames

From: Eric Ridge <eebbrr(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Regina Obe <lr(at)pcorp(dot)us>, strk(at)kbt(dot)io, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Regina Obe <r(at)pcorp(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [PATCH] Support % wildcard in extension upgrade filenames
Date: 2023-05-01 18:25:24
Message-ID: 86875FF7-0592-4F76-8CBA-8B5AE632F1B2@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> On May 1, 2023, at 12:12 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Fri, Apr 28, 2023 at 10:03 AM Eric Ridge <eebbrr(at)gmail(dot)com> wrote:
>> ZomboDB has 137 releases over the past 8 years.
>
> Dang.
>
> This may be one of those cases where the slow pace of change for
> extensions shipped with PostgreSQL gives those of us who are
> developers for PostgreSQL itself a sort of tunnel vision.

Could be I'm a terrible programmer too. Could be Elasticsearch is a PITA to deal with.

FWIW, outside of major ZDB releases, most of those have little-to-zero schema changes. But that doesn't negate the fact each release needs its own upgrade.sql script. I'm working on a point release right this moment and it won't have any schema changes but it'll have an upgrade.sql script.

Maybe related, pgrx (formally pgx) has had 77 release since June 2020, but that's mostly us just slowly trying to wrap Postgres internals in Rust, bug fixing, and such. Getting support for a new major Postgres release usually isn't *that* hard -- a day or two of work, depending on how drastically y'all changed an internal API. `List` and `FunctionCallInfo(Base)Data` come to mind as minor horrors for us, hahaha. Rust at least makes it straightforward for us to have divergent implementations and have the decisions solved at compile time.

> The system
> that we have in core works well for those extensions, which get a new
> version at most once a year and typically much less often than that.
> I'm not sure we'd be so sanguine about the status quo if we had 137
> releases out there.

I don't lose sleep over it but it is a lot of bookkeeping. The nice thing about Postgres' extension system is that we can do what we want without regard to the project's release schedule. In general, y'all nailed the extension system back in the day.

I feel for the PostGIS folks as they've clearly got more, hmm, complete Postgres version support than ZDB does, and I'd definitely want to support anything that would make their lives easier. But I also don't want to see something that pgrx users might want to adopt that might turn out to be bad for them.

I have a small list of things I'd love to see changed wrt extensions but I'm just the idea guy and don't have much in the way of patches to offer. I also have some radical ideas about annotating the sources themselves, but I don't feel like lobbing a grenade today.

eric

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Maciek Sakrejda 2023-05-01 19:03:38 Re: Overhauling "Routine Vacuuming" docs, particularly its handling of freezing
Previous Message Peter Geoghegan 2023-05-01 17:09:06 Re: Overhauling "Routine Vacuuming" docs, particularly its handling of freezing