Re: proposal - get_extension_version function - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: proposal - get_extension_version function
Date
Msg-id CAAWbhmhmFgaNVyAYa1A++ynW6RCC7AbV_7w3Bms934jxG0vkDw@mail.gmail.com
Whole thread Raw
In response to Re: proposal - get_extension_version function  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: proposal - get_extension_version function  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Mar 8, 2023 at 1:47 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Pavel's proposed check would break that too.  There's going to be some
> interval where the SQL definitions are not in sync with the .so version,
> so you really want the .so to support at least two versions' worth of
> SQL objects.

I think we're in agreement that the extension must be able to load
with SQL version X and binary version X+1. (Pavel too, if I'm reading
the argument correctly -- the proposal is to gate execution paths, not
init time. And Pavel's not the only one implementing that today.)

What I'm trying to pin down is the project's position on the reverse
-- binary version X and SQL version X+1 -- because that seems
generally unmaintainable, and I don't understand why an author would
pay that tax if they could just avoid it by bailing out entirely. (If
an author wants to allow that, great, but does everyone have to?)

--Jacob



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: meson: Optionally disable installation of test modules
Next
From: Matthias van de Meent
Date:
Subject: Re: Ignoring BRIN for HOT updates (was: -udpates seems broken)