Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1u7aVL-0028dl-I8 for pgsql-hackers@arkaria.postgresql.org; Wed, 23 Apr 2025 13:51:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1u7aVJ-006Z7l-Fj for pgsql-hackers@arkaria.postgresql.org; Wed, 23 Apr 2025 13:51:10 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1u7aVJ-006Z7d-5k for pgsql-hackers@lists.postgresql.org; Wed, 23 Apr 2025 13:51:10 +0000 Received: from mout-p-202.mailbox.org ([2001:67c:2050:0:465::202]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1u7aVE-001Xer-0M for pgsql-hackers@lists.postgresql.org; Wed, 23 Apr 2025 13:51:09 +0000 Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4ZjL9D1R1pz9sq6; Wed, 23 Apr 2025 15:50:56 +0200 (CEST) Date: Wed, 23 Apr 2025 15:50:54 +0200 From: Christoph Berg To: Matheus Alcantara Cc: Peter Eisentraut , pgsql-hackers@lists.postgresql.org, "David E. Wheeler" Subject: Re: extension_control_path and "directory" Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Re: Matheus Alcantara > I've tried to implement some kind of "SHAREDIR search path" as we've > discussed on another thread [1] but it shows out that we need some > considerable refactoring to make it work. Remembering which path the .control file was found in and from there open the extension "directory" doesn't sound too hard. Why does it have to be more complicated? Also, re-running a search path discovery for the directory is probably just wrong, if there are different extension versions in the "control" search path and the "extensions" search path, it might lead to weird version skew problems. > Talking with Peter privately IIUC we concluded that we may document > this limitation that using extension control path with an extension that > uses a custom "directory" field on .control file will not work. I think > that we may add a note section on "extension_control_path" doc on [2], > what do you think? Seen from Debian, this would be a regression since it worked with my custom patch. The number of extensions using that feature is limited, though, so it wouldn't be a huge problem: $ grep directory */*/*.control pgfincore/pgfincore/pgfincore.control:directory = pgfincore postgresql-pgmp/postgresql-pgmp/pgmp.control:directory = 'pgmp' postgresql-semver/postgresql-semver/semver.control:directory = 'semver' (Not including extensions generating the .control file at build time.) Christoph