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

From Andrew Dunstan
Subject Re: Avoid leaking system path from pg_available_extensions
Date
Msg-id 5ce9de1e-0b89-4c62-ab3e-9e4513ba69b7@dunslane.net
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
List 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




pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [PATCH] Reject ENCODING option for COPY TO FORMAT JSON
Next
From: Henson Choi
Date:
Subject: Re: Row pattern recognition