On Wed, Mar 8, 2023 at 11:18 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > 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.
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. > 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. 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
