Re: proposal - get_extension_version function
От | Pavel Stehule |
---|---|
Тема | Re: proposal - get_extension_version function |
Дата | |
Msg-id | CAFj8pRBsK+XZxeWgj369aCtW48whMg6hbeTZoYuqB4UvjN9Q7w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: proposal - get_extension_version function (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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.
regards, tom lane
В списке pgsql-hackers по дате отправления: