Re: proposal - get_extension_version function
От | Tom Lane |
---|---|
Тема | Re: proposal - get_extension_version function |
Дата | |
Msg-id | 256978.1678315405@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: proposal - get_extension_version function (Jacob Champion <jchampion@timescale.com>) |
Ответы |
Re: proposal - get_extension_version function
|
Список | pgsql-hackers |
Jacob Champion <jchampion@timescale.com> writes: > What I'm trying to pin down is the project's position on the reverse > -- binary version X and SQL version X+1 -- because that seems > generally unmaintainable, and I don't understand why an author would > pay that tax if they could just avoid it by bailing out entirely. (If > an author wants to allow that, great, but does everyone have to?) Hard to say. Our experience with the standard contrib modules is that it really isn't much additional trouble; but perhaps more-complex modules would have more interdependencies between functions. In any case, I fail to see the need for basing things on a catalog lookup rather than embedding API version numbers in relevant C symbols. regards, tom lane
В списке pgsql-hackers по дате отправления: