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

> On Nov 11, 2026, at 00:30, Matheus Alcantara <matheusssilv97(at)gmail(dot)com> wrote:
>
> 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!
>

V4 LGTM too.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/