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: Matheus Alcantara <matheusssilv97@gmail.com>
Cc: Jim Jones <jim.jones@uni-muenster.de>,
PostgreSQL-development <pgsql-hackers@postgresql.org>,
Andrew Dunstan <andrew@dunslane.net>
Date: 2026-05-26T07:14:25Z
Lists: pgsql-hackers
Attachments
- v2-0001-Avoid-leaking-system-path-from-pg_available_exten.patch (application/octet-stream)
> 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. > > -- > Matheus Alcantara > EDB: https://www.enterprisedb.com 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. Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/