MIME-Version: 1.0
References: <E1tumbY-003Dl3-2o@gemulon.postgresql.org>
 <aAi1VACxhjMhjFnb@msg.df7cb.de>
 <CAFY6G8dDjimxaSQV68ExWMmrAi8xNhiOT3RZOD8oQZmdGCG5Jg@mail.gmail.com>
 <aAjwPjsIElh17Nby@msg.df7cb.de>
 <3C304C9E-976C-4FB9-A883-707E0B90756A@justatheory.com>
 <CAFY6G8c=W8CMFwcx2fA0RSFtvw=5BDGKOjGSV=nEUiZ6use2Bw@mail.gmail.com>
 <aAoQkqwktHQI5KLO@msg.df7cb.de>
 <CAFY6G8d-4Nb34dqb_92kGrXfo4tO012m-9YzznKmb7f5JhJpEA@mail.gmail.com>
 <546E7C54-D2F4-4DBB-9A06-EBBF90265A2C@justatheory.com>
 <CAFY6G8fjaVpkZHFk3CQR=ShiysZ3Y_ti568-vuKYOrMepLB_sQ@mail.gmail.com>
 <672C8C5E-519A-4B39-9421-E6C31917B271@justatheory.com>
 <CAFY6G8dwnxqBDcQbVYfjJJ6RYMTxc04gip64Nx7X2fk4ggA+rQ@mail.gmail.com>
 <FD339F84-2BCE-4994-B298-388EEF179892@justatheory.com>
In-Reply-To: <FD339F84-2BCE-4994-B298-388EEF179892@justatheory.com>
From: Matheus Alcantara <matheusssilv97@gmail.com>
Date: Tue, 29 Apr 2025 10:49:09 -0300
Message-ID: 
 <CAFY6G8cmNw6H=Xz8Q45eKVy9aSKLy+GASGiq55nsnyxVo_pcwg@mail.gmail.com>
Subject: Re: extension_control_path and "directory"
To: "David E. Wheeler" <david@justatheory.com>
Cc: Christoph Berg <myon@debian.org>, Peter Eisentraut <peter@eisentraut.org>,
	pgsql-hackers@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAFY6G8cmNw6H%3DXz8Q45eKVy9aSKLy%2BGASGiq55nsnyxVo_pcwg%40mail.gmail.com>
Precedence: bulk

On Mon, Apr 28, 2025 at 5:49=E2=80=AFPM David E. Wheeler <david@justatheory=
.com> wrote:
>
> > To append the /extension at each path on extension_control_path would
> > require some changes on find_in_path() that
> > find_extension_control_filename() calls, which I think that it would
> > make the function more complicated. I've them created a similar
> > find_in_paths() function that works in the same way but it receives a
> > List of paths instead of the string of paths separated by ":". We can
> > get this List of paths using get_extension_control_directories() that
> > also handle the macro substitution like find_in_path().
> >
> > Attached v4 with these fixes. I hope that now you should be able to omi=
t
> > the /extension from the GUC value.
>
> Yes! It now works with this configuration:
>
> ```ini
> extension_control_path =3D '/Users/david/Downloads/share/postgresql:$syst=
em'
> dynamic_library_path =3D '/Users/david/Downloads/lib/postgresql:$libdir=
=E2=80=99
> ```
>
> Which is nicely more consistent. Kind of want that first one to be called=
 =E2=80=9Cshare_path=E2=80=9D now, though, since it=E2=80=99s not just exte=
nsions. Although I guess it=E2=80=99s only extension control file searching=
 that uses it (for now).
>
Thanks for testing!

> If I understand this bit correctly:
>
> ```c
>             /* Substitute the path macro if needed */
> mangled =3D substitute_path_macro(piece, "$system", system_dir);
>
> /*
> * Append "extension" suffix in case is a custom extension control
> * path.
> */
> if (strcmp(piece, "$system") !=3D 0)
> mangled =3D psprintf("%s/extension", mangled);
> ```
>
> The value of `piece` is a single path from the search path, right? If so,=
 I think it=E2=80=99s either `$system` or something else; I don=E2=80=99t i=
t would ever be that `$system` is a substring of a single path. Is that rig=
ht?
>
Yes, it is a single path from the search path, in your case it will be
"/Users/david/Downloads/share/postgresql" and "$system". We split these
paths based on the system path separator and get the next "piece" here:

            char       *piece =3D first_path_var_separator(ecp);

The first_path_var_separator() changes the "ecp" parameter on every call,
it returns the next path on "ecp" and changes it to have the remaining
paths to iterate over it.


> Other than that, I think this patch is good to go. Thanks!
>
Thanks for reviewing!

--=20
Matheus Alcantara