Re: extension_control_path: ignore empty elements and deduplicate directories

> On Nov 12, 2026, at 02:54, Matheus Alcantara <matheusssilv97(at)gmail(dot)com> wrote:
>
> On 10/11/26 16:27, Matheus Alcantara wrote:
>> Regarding the backpatch, I don't think that having a different behaviour
>> on master and on the back branches is a good idea. If '$system:' raises
>> an error on 20 but is silently ignored on 18 and 19, the same setting
>> behaves differently depending on the version, which seems confusing to
>> me, especially for a parameter that was only introduced on 18. I think
>> that we should either raise the error on all branches or silently ignore
>> the empty elements on all branches, and then backpatch whichever we
>> choose. (CCing Peter so we can get a committer thought on this).
>
> I talked with Peter off list and it seems that just silently ignore
> the error is the better approach to take here.
>
> We currently don't raise an error for non-existing paths so I think
> that it's ok to just ignore non-applicable path elements.
>

Hi Matheus,

Thank you so much for discussing this with Peter and bringing the message back.

For 0001, we can revert to v1’s approach and silently discard empty path elements from extension_control_path.

One thing to note is that a completely empty extension_control_path ('') will still be interpreted as $system, preserving the existing behavior. A value containing only separators, such as ':', will provide no search directories, so no extensions will be found.

For 0002, I revisited the example Surya provided:
```
SET extension_control_path = '$system:rel';
SELECT name, location FROM pg_available_extensions WHERE name = 'relext';
name | location
--------+---------------
relext | rel/extension

CREATE EXTENSION relext;
ERROR: component in parameter "extension_control_path" is not an absolute path
```

I think the key problem is that pg_available_extensions lists extensions found through relative paths, but CREATE EXTENSION fails when it reaches a relative path, before searching that directory.

So I think we can also silently discard relative path elements. In the example above, pg_available_extensions will return no row for relext, and CREATE EXTENSION will fail with extension "relext" is not available, assuming relext is available only through rel. This approach also eliminates the inconsistency.

This introduces a behavior change for CREATE EXTENSION. For example, with extension_control_path = '/path1:relative:/path2', CREATE EXTENSION currently fails if the search reaches 'relative'. With v5-0002, it will skip that element and proceed if the extension is found in /path2; otherwise, it will report that the extension is not available. I think that should be fine.

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