Re: Add Postgres module info
От | Andrei Lepikhov |
---|---|
Тема | Re: Add Postgres module info |
Дата | |
Msg-id | c41a4cbc-608f-45ff-8642-49ffc7c85745@gmail.com обсуждение исходный текст |
Ответ на | Re: Add Postgres module info (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 3/23/25 20:10, Tom Lane wrote: > Andrei Lepikhov <lepihov@gmail.com> writes: >> On 3/22/25 23:49, Tom Lane wrote: >>> * It is not clear to me what permission restrictions we should put >>> on pg_get_loaded_modules, ... > >> I vote for the idea of stripping the full path to just a filename. > > Works for me. v7 attached does it that way. Thanks, you've done almost all the job. > >>> * I'm not happy with putting pg_get_loaded_modules into dfmgr.c. > >> I just attempted to reduce number of exported objects here. If it is ok >> to introduce an iterator, the pg_get_loaded_modules() may live in >> extension.c > > Yeah, I like that better than leaving it in dfmgr.c, so done that way. > The iterator functions also provide some cover for dealing with > on-the-fly changes of the file list, if we ever need that. It also gives extension developers a tool to detect conflicting modules any time we need it. More elegant than the SerializeLibraryState(). > > I converted pg_get_loaded_modules to run just once and deliver its > results in a tuplestore. That's partly because the adjacent SRFs > in extension.c work like that, but mostly because it removes the > hazard of the file list changing mid-run. Ok. >> Yes, additional burden to bump version string was a stopper for me to >> propose such a brave idea. > > After sleeping on it, I think we really ought to do that, so 0002 > attached does so. With the concept of the PG_VERSION string as a version, it looks more meaningful than I've thought before. Patch 0001 is ready to commit for me. Patch 0002 I just checked on the errors in module names. That's more I can do here? ;) Seems good, no errors found. -- regards, Andrei Lepikhov
В списке pgsql-hackers по дате отправления: