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

From Jim Jones
Subject Re: Avoid leaking system path from pg_available_extensions
Date
Msg-id 8460e17f-7fa1-4df1-b007-e1b234f18064@uni-muenster.de
Whole thread
In response to Re: Avoid leaking system path from pg_available_extensions  (Chao Li <li.evan.chao@gmail.com>)
List 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’mnot 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
atthe 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




pgsql-hackers by date:

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