Re: Avoid leaking system path from pg_available_extensions - Mailing list pgsql-hackers

From Chao Li
Subject Re: Avoid leaking system path from pg_available_extensions
Date
Msg-id 83AF10FE-7655-43DF-A302-3CAC796B572F@gmail.com
Whole thread
In response to Re: Avoid leaking system path from pg_available_extensions  (Matheus Alcantara <matheusssilv97@gmail.com>)
Responses Re: Avoid leaking system path from pg_available_extensions
Re: Avoid leaking system path from pg_available_extensions
List pgsql-hackers

> 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
notsure 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
thebeginning 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/





Attachment

pgsql-hackers by date:

Previous
From: "Zizhuan Liu"
Date:
Subject: Re:[PATCH] Little refactoring of portalcmds.c
Next
From: "Jelte Fennema-Nio"
Date:
Subject: Re: libpq maligning postgres stability