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/[email protected] -- Matheus Alcantara EDB: https://www.enterprisedb.com
