Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\))
Subject: Re: [PATCH] Support % wildcard in extension upgrade filenames
From: Eric Ridge <eebbrr@gmail.com>
In-Reply-To: 
 <CA+TgmobhF+VOCLETv3ewNTdP6Y04V1Lh5jy1N45VRJoNER8PNw@mail.gmail.com>
Date: Mon, 1 May 2023 14:25:24 -0400
Cc: Regina Obe <lr@pcorp.us>,
 strk@kbt.io,
 Tom Lane <tgl@sss.pgh.pa.us>,
 Regina Obe <r@pcorp.us>,
 pgsql-hackers@lists.postgresql.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <86875FF7-0592-4F76-8CBA-8B5AE632F1B2@gmail.com>
References: <YgakFklJyM5pNdt+@c19> <20221117095734.igldlk6kngr6ogim@c19>
 <166914379479.1121.7549798686571352890.pgcf@coridan.postgresql.org>
 <55512.1673304709@sss.pgh.pa.us> <20230110205259.htcuhg3t7shd367d@c19>
 <387183.1673394631@sss.pgh.pa.us>
 <CA+TgmobDy0sasmzOFkCcKXC3XeQZzRNwbaQRJ752tF1i11BRKQ@mail.gmail.com>
 <20230308122736.e2mx4e3paxbabcnw@c19>
 <CA+TgmoYqK6nfP15SjuyO6t5jOmymG=qO7JOOVJdTOj96L0XJ1Q@mail.gmail.com>
 <20230313122210.r7mnwawjhfklcp7w@c19>
 <003201d955dc$7770af60$66520e20$@pcorp.us>
 <F2820A88-F29B-4F0A-9430-7D9AE33E953C@gmail.com>
 <CA+TgmobhF+VOCLETv3ewNTdP6Y04V1Lh5jy1N45VRJoNER8PNw@mail.gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/86875FF7-0592-4F76-8CBA-8B5AE632F1B2%40gmail.com>
Precedence: bulk


> On May 1, 2023, at 12:12 PM, Robert Haas <robertmhaas@gmail.com> =
wrote:
>=20
> On Fri, Apr 28, 2023 at 10:03=E2=80=AFAM Eric Ridge <eebbrr@gmail.com> =
wrote:
>> ZomboDB has 137 releases over the past 8 years.
>=20
> Dang.
>=20
> 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=