public inbox for [email protected]  
help / color / mirror / Atom feed
From: Peter Eisentraut <[email protected]>
To: Matheus Alcantara <[email protected]>
Cc: Andrew Dunstan <[email protected]>
Cc: Gabriele Bartolini <[email protected]>
Cc: Craig Ringer <[email protected]>
Cc: David E. Wheeler <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: RFC: Additional Directory for Extensions
Date: Wed, 19 Mar 2025 07:42:44 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAFY6G8d56BK5TZ7K+uw4DHLZ=9Th3p+E1x4pp26nJ_K5k4EUwA@mail.gmail.com>
References: <CA+TgmoaMk==vOUmWwJ5ZA-EueNqa9RQaWMEiHCF1ZKW_YCcj8g@mail.gmail.com>
	<[email protected]>
	<CAGRY4nx8Fmea4udk--PKdvfgpNdqC+rcueAmGwuw2PD9dv+zqQ@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAFY6G8dzuLXFjONX5E-TvyD5E9r21b5vp1My_nMcqdGD0VYfYw@mail.gmail.com>
	<[email protected]>
	<CAFY6G8dGcv1D8tCkjrz+9DvAYG9h4U=hBm0VXjJEXExy44hauQ@mail.gmail.com>
	<CAFY6G8eOMkGXLqzUz=qXrwt4X_HvmVZ13570DAbgAiw+3q03DA@mail.gmail.com>
	<CAFY6G8fV5FTqn7p8pxbvPYUD5+ffik-J50GChjKH2Gg7d=fRPg@mail.gmail.com>
	<[email protected]>
	<CAFY6G8cGeUV0f5K8v-Du0ts3iZyRE6Q5dNtYjQq8cjS4epLX5A@mail.gmail.com>
	<[email protected]>
	<CAFY6G8d56BK5TZ7K+uw4DHLZ=9Th3p+E1x4pp26nJ_K5k4EUwA@mail.gmail.com>

On 12.03.25 14:17, Matheus Alcantara wrote:
>> There should be a simpler way into this.  Maybe
>> pg_available_extensions() should fill out the ExtensionControlFile
>> structure itself, set ->control_dir with where it found it, then call
>> directly to parse_extension_control_file(), and that should skip the
>> finding if the directory is already set.  Or something similar.
>>
> Good catch. I fixed this by creating a new function to construct the
> ExtensionControlFile and changed the pg_available_extensions to set the
> control_dir. The read_extension_control_file was also changed to just
> call this new function constructor. I implemented the logic to check if
> the control_dir is already set on parse_extension_control_file because
> it seems to me that make more sense to not call
> find_extension_control_filename instead of putting this logic there
> since we already set the control_dir when we find the control file, and
> having the logic to set the control_dir or skip the find_in_path seems
> more confusing on this function instead of on
> parse_extension_control_file. Please let me know what you think.

Committed that, thanks.

A small tweak I made was to replace palloc+snprintf by psprintf.  Maybe 
you were not aware that that function exists.

I also simplified the error handling in parse_extension_control_file() a 
bit.  If we pass in a control directory (which is the new code we're 
adding), then we can assume that we already found the file earlier, and 
then if we now don't find it, then we should just report the file system 
error instead of the "you should install this extension first" error. 
It's kind of a "can't happen" error anyway, so the different is small.






view thread (47+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: RFC: Additional Directory for Extensions
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox