Re: Avoid leaking system path from pg_available_extensions
Chao Li <li.evan.chao@gmail.com>
From: Chao Li <li.evan.chao@gmail.com>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Matheus Alcantara <matheusssilv97@gmail.com>,
Jim Jones <jim.jones@uni-muenster.de>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2026-05-31T04:26:51Z
Lists: pgsql-hackers
> On May 30, 2026, at 21:21, Andrew Dunstan <andrew@dunslane.net> wrote: > > > 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 Thanks for pushing. Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/