Re: extension_control_path: ignore empty elements and deduplicate directories

On Thu Nov 12, 2026 at 12:05 AM -03, Chao Li wrote:
> 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.
>

Thanks for the new version!

I tested v5 on master and REL_19_STABLE, where it applies cleanly and
the TAP tests pass. With '$system:', ':$system', '$system:rel',
'rel:$system' and '$system/foo:$system', pg_available_extensions,
CREATE EXTENSION and the unknown-language hint now behave the same, and
'' still means $system.

Just a note about the 0001 tests: they also pass on master without the
patch. On master an empty element is expanded to /extension, which
usually doesn't exist, so it's just skipped and the extension is still
found on the remaining directories. The difference is only visible if
/extension exists, which we can't create on a TAP test, so I don't think
that there is anything we can do here, but the tests are still useful to
prevent regressions. The 0002 tests fail on master as expected.

v5 doesn't apply on REL_18_STABLE, since get_extension_control_directories()
there returns a List of plain char * paths instead of ExtensionLocation,
and pg_available_extensions doesn't have the location column. The
attached patches are a backport of v5 to REL_18_STABLE. The changes are:

- The empty and relative element checks are the same, but applied to
the List of char * paths, using the "$system" string directly since
there is no EXTENSION_SYSTEM_MACRO on 18.
- find_in_paths() is made static and simplified in the same way.
- The tests that check the location column were changed to check
whether the extension is listed with count(*), and use $ext_dir since
$ext_dir_canonicalized doesn't exist on the 18 test.

The patches have the .nocfbot suffix so they don't break the CFBot.

I'm attaching as v6, but 0001 and 0002 are unchanged.

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