Re: glob support in extension_control_path/dynamic_library_path?

> Am 24.06.2026 um 23:19 schrieb Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>:
>
> The current patch simply takes a wildcard, and evaluates it every time
> it is needed. Is that the correct approach?
> [...]
>
> Wouldn't it be better to freeze the current list of matching
> directories on configuration load, and require pg_reload_conf to add
> the newly matching patterns?

This would be very confusing for users and undermine the main use case of adding glob support. The point of glob support is to reduce the complexity of packaging. If we need to manually reload the configuration after adding a directory, we could also just add the new directory to the extension_control_path GUC. This is what we currently do for Postgres.app, and glob support should make this easier.

Currently, PostgreSQL scans the file system every time it looks for extensions. It makes sense to also resolve the glob at that time.

If we resolve the glob when the backend starts, and then later search the resolved paths for extension control files, we are scanning the file system at two different points in time. This has a high potential for confusing users. Some changes (eg. adding files to directories) would show up immediately, but others (eg. renaming a directory) would require reloading the configuration.

If you actually wanted predictable results, you would need to store a complete snapshot of all exiting extension control files and dynamic libraries at server start instead of resolving them on demand as PostgreSQL currently does. And at load time you would need to verify the control files haven't changed in the mean time. But this seems futile. If an attacker already has write access to extension control directories, it's hard to think of a scenario where these extra checks would be helpful.

Best regards,
Jakob