st 8. 3. 2023 v 19:49 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Pavel Stehule <pavel.stehule@gmail.com> writes: > I try to write a safeguard check that ensures the expected extension > version for an extension library.
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? You need to make the C code as forgiving as possible, not as unforgiving as possible.
This method doesn't break updates. It allows any registration, just doesn't allow execution with unsynced SQL API.
If you have C-level ABI changes you need to make, the usual fix is to include some sort of version number in the C name of each individual function you've changed, so that calls made with the old or the new SQL definition will be routed to the right place. There are multiple examples of this in contrib/.
In my extensions like plpgsql_check I don't want to promise compatible ABI. I support PostgreSQL 10 .. 16, and I really don't try to multiply code for any historic input/output.
