Re: [PATCH] doc: Fix description of relative extension "directory" setting

On Tue Nov 10, 2026 at 11:24 AM -03, Mahendrakar Srinivasarao wrote:
>> The attached v3 includes a 0002 that fixes the docs for this.
>
> I can reproduce it: with extension_control_path = '$system/foo',
> pg_available_extensions returns no rows and CREATE EXTENSION fails with
> "component in parameter "extension_control_path" is not an absolute
> path". It's even more confusing when combined with a valid element:
> with extension_control_path = '$system/foo:$system',
> pg_available_extensions lists the extensions from $system (the bad
> element is silently skipped as a nonexistent directory), but CREATE
> EXTENSION on any of them still fails with the same error, because
> find_in_paths() rejects the first element before it gets to $system.
>
>
> 0002 looks good and is included in v4 unchanged.
>

Thanks for checking!

> Two related things I noticed while testing:
>
> - The long_desc of extension_control_path in guc_parameters.dat
> (guc_tables.c on 18) has the same "loaded from the same directory
> where the primary control file was found" sentence that 0001 fixes in
> config.sgml. The new 0003 adjusts it to match. Since it's a
> translatable string, I've kept it separate and meant it for master
> only, so 0001 and 0002 can be backpatched without it.
>

Good.

> - The '$system/foo:$system' inconsistency comes from find_in_paths()
> and pg_available_extensions handling an invalid element differently,
> and from nothing validating the value when it's set. Would a check
> hook that rejects such elements at SET time be worth pursuing? One
> concern is that it could break existing setups: a value like
> '$system:$system/foo' works today for any extension found in $system,
> but with a check hook it would be rejected, and in postgresql.conf
> that would prevent the server from starting after an upgrade.
> dynamic_library_path also only validates its elements when they're
> used. If there's interest I can start a separate thread for that;
> it's not addressed in v4.
>

This seems related with another discussion about an
extension_control_path bug [1] that accepts an empty path element and
append /extension by mistake. I think that we can discuss about this
case on this other thread.

> v4-0001 and v4-0002 are rebased on current master and apply cleanly to
> REL_19_STABLE and REL_18_STABLE; the docs build without warnings.
> v4-0003 applies on master (and REL_19_STABLE, if wanted there); it
> builds and passes make check.

v4 looks good to me, thanks!

I've moved the CF entry from drafts to PG20-4. If there is no other
comments on this I think that we can mark this as Ready for Committer in
the following days.

[1] https://www.postgresql.org/message-id/DC2D9FA5-45C4-494F-99FC-F9B95AD4FF55@gmail.com

--
Matheus Alcantara
EDB: https://www.enterprisedb.com