Re: Avoid leaking system path from pg_available_extensions
Andrew Dunstan <andrew@dunslane.net>
From: Andrew Dunstan <andrew@dunslane.net>
To: Matheus Alcantara <matheusssilv97@gmail.com>,
Chao Li <li.evan.chao@gmail.com>
Cc: Jim Jones <jim.jones@uni-muenster.de>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2026-05-30T13:21:21Z
Lists: pgsql-hackers
On 2026-05-26 Tu 9:29 AM, Matheus Alcantara wrote: > On 26/05/26 04:14, Chao Li wrote: >> >> >>> On May 22, 2026, at 23:40, Matheus Alcantara >>> <matheusssilv97@gmail.com> wrote: >>> >>> On 22/05/26 04:25, Jim Jones wrote: >>>> On 21/05/2026 17:12, Matheus Alcantara wrote: >>>>> I've reproduced the issue and the fix looks correct to me. >>>> same here, +1 >>> >>> Thank you for also testing. >>> >>>> I was wondering if creating a constant for it would be, stylistically >>>> speaking, a cleaner solution. For instance: >>>> #define EXTENSION_SYSTEM_MACRO "$system" >>>> I realize that it's used only inside >>>> get_extension_control_directories() >>>> but since it is even mentioned in the docs, I guess it wouldn't be >>>> a bad >>>> idea. >>> >>> I'm not against it but I don't think that it's necessary since as >>> you mention, only get_extension_control_directories() use. >>> >> >> In theory, I’m not against the idea either. In practice, there are >> many hard-coded strings in the source tree, and I’m not sure where >> the right place would be to define this macro. >> >> Since this string is only used in >> get_extension_control_directories(), and now it is used three times, >> I defined it at the beginning of the function and undefined it at the >> end. Let’s see if there are any objections to that. >> >> Please see the attached v2. >> > > We have such pattern in other parts of the codebase (e.g > pg_resetwal.c), so it works for me. > > Thanks for the patch. > > Pushed. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com