Re: Avoid leaking system path from pg_available_extensions

From: Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>
To: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Matheus Alcantara <matheusssilv97(at)gmail(dot)com>
Cc: 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 10:02:45
Message-ID: 8460e17f-7fa1-4df1-b007-e1b234f18064@uni-muenster.de
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 26/05/2026 09:14, Chao Li wrote:
> 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.

I don't feel strongly about it. I only brought it up because hardcoded
strings used in multiple places are usually a recipe for oversights and
painful debugging down the road. That said, as I mentioned, I understand
the argument that this is scoped to a single function, and the fact
they're pretty close to one another also makes it less likely to be
missed, but there is no guarantee it'll stay like that forever.

Thanks for the fix!

Best, Jim

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2026-05-26 11:09:13 Re: NULL pointer dereference in syslogger with load_libraries() and -DEXEC_BACKEND at startup
Previous Message Andriy Dorokhin 2026-05-26 09:54:21 RFC: Boyer-Moore-Horspool optimization for LIKE '%pattern%' searches