| From: | Matheus Alcantara <matheusssilv97(at)gmail(dot)com> |
|---|---|
| To: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
| Cc: | Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Subject: | Re: Avoid leaking system path from pg_available_extensions |
| Date: | 2026-05-26 13:29:58 |
| Message-ID: | bd4b316a-d0cd-4ccf-b9fe-18621c953645@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 26/05/26 04:14, Chao Li wrote:
>
>
>> On May 22, 2026, at 23:40, Matheus Alcantara <matheusssilv97(at)gmail(dot)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.
--
Matheus Alcantara
EDB: https://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | shveta malik | 2026-05-26 12:32:09 | Re: effective_wal_level is not decreasing after using REPACK (CONCURRENTLY) |