On 3/23/25 20:10, Tom Lane wrote:
Andrei Lepikhov <lepi...@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
