Re: proposal - get_extension_version function

st 8. 3. 2023 v 20:17 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:

> Jacob Champion <jchampion(at)timescale(dot)com> writes:
> > On Wed, Mar 8, 2023 at 10:49 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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.
>

There is agreement - I call this check from functions.

https://github.com/okbob/plpgsql_check/commit/b0970ff319256207ffe5ba5f18b2a7476c7136f9

Regards

Pavel

> regards, tom lane
>