Subject: Re: proposal - get_extension_version function

From: Tom Lane <[email-masked]>
Date: Wed, 08 Mar 2023 14:17:56 -0500

Jacob Champion <[email-masked]> writes:
> On Wed, Mar 8, 2023 at 10:49 AM Tom Lane <[email-masked]> wrote:
>> This is a bad idea.  How will you do extension upgrades, if the new .so
>> won't run till you apply the extension upgrade script but the old .so
>> malfunctions as soon as you do?

> Which upgrade paths allow you to have an old .so with a new version
> number? I didn't realize that was an issue.

More usually, it's the other way around: new .so but SQL objects not
upgraded yet.  That's typical in a pg_upgrade to a new major version,
where the new installation may have a newer extension .so than the
old one did.  You can't run ALTER EXTENSION UPGRADE if the new .so
refuses to load with the old SQL objects ... which AFAICS is exactly
what Pavel's sketch would do.

If you have old .so and new SQL objects, it's likely that at least
some of those new objects won't work --- but it's good to not break
any more functionality than you have to.  That's why I suggest
managing the compatibility checks on a per-function level rather
than trying to have an overall version check.

			regards, tom lane

---

From: Jacob Champion <[email-masked]>
Date: Wed, 8 Mar 2023 13:10:25 -0800

On Wed, Mar 8, 2023 at 11:18 AM Tom Lane <[email-masked]> wrote:
> old one did.

That's the opposite case though; I think the expectation of backwards
compatibility from C to SQL is very different from (infinite?)
forwards compatibility from C to SQL.

> any more functionality than you have to.

To me it doesn't seem like a partial break is safer than refusing to
execute in the face of old-C-and-new-SQL -- assuming it's safe at all?
A bailout seems pretty reasonable in that case.

Thanks,
--Jacob