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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: proposal - get_extension_version function
Следующее
От: Daniel Gustafsson
Дата:
Сообщение: Re: lz4 --rm on Ubuntu 18.04 (Add LZ4 compression to pg_dump)