Re: Add Postgres module info
От | Andrei Lepikhov |
---|---|
Тема | Re: Add Postgres module info |
Дата | |
Msg-id | 2c215c98-f713-4c5b-b21a-a4b8fa41890b@gmail.com обсуждение исходный текст |
Ответ на | Re: Add Postgres module info (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Add Postgres module info
|
Список | pgsql-hackers |
On 12/12/2024 01:21, Tom Lane wrote: > Andrei Lepikhov <lepihov@gmail.com> writes: >> I would like to propose the module_info structure, which aims to let >> extension maintainers sew some data into the binary file. Being included >> in the module code, this information remains unchanged and is available >> for reading by a backend. > > I don't have much of an opinion one way or the other about the > usefulness of these additional info fields. But I would like to > object to the way you've gone about it, namely to copy-and-paste > the magic-block mechanism. That doesn't scale: the next time > somebody else wants some more fields, will we have three such > structs? It makes sense. But I want to clarify that I avoided changing PG_MODULE_MAGIC because the newly introduced structure has a totally different purpose and usage logic: the struct is designed to check compatibility, but module info isn't connected to the core version at all: a single version of the code may be built for multiple PG versions. At the same time, various versions of the same library may be usable with the same core. From the coding point of view, I agree that your approach is more laconic and reasonable. I will rewrite the code using this approach. -- regards, Andrei Lepikhov
В списке pgsql-hackers по дате отправления: