st 8. 3. 2023 v 20:17 odesílatel Tom Lane <t...@sss.pgh.pa.us> napsal:
> Jacob Champion <jchamp...@timescale.com> writes: > > On Wed, Mar 8, 2023 at 10:49 AM Tom Lane <t...@sss.pgh.pa.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 >
