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 1u7thn-009ISW-EW for pgsql-hackers@arkaria.postgresql.org; Thu, 24 Apr 2025 10:21:19 +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 1u7thl-00FiA8-Am for pgsql-hackers@arkaria.postgresql.org; Thu, 24 Apr 2025 10:21:18 +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 1u7thl-00Fi8f-0X for pgsql-hackers@lists.postgresql.org; Thu, 24 Apr 2025 10:21:17 +0000 Received: from mout-p-201.mailbox.org ([2001:67c:2050:0:465::201]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1u7thi-001gzV-2H for pgsql-hackers@lists.postgresql.org; Thu, 24 Apr 2025 10:21:16 +0000 Received: from smtp1.mailbox.org (smtp1.mailbox.org [IPv6:2001:67c:2050:b231:465::1]) (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-201.mailbox.org (Postfix) with ESMTPS id 4ZjsSh5Mcqz9sdT; Thu, 24 Apr 2025 12:21:08 +0200 (CEST) Date: Thu, 24 Apr 2025 12:21:06 +0200 From: Christoph Berg To: Matheus Alcantara Cc: "David E. Wheeler" , Peter Eisentraut , pgsql-hackers@lists.postgresql.org Subject: Re: extension_control_path and "directory" Message-ID: References: <3C304C9E-976C-4FB9-A883-707E0B90756A@justatheory.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4ZjsSh5Mcqz9sdT List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Re: Matheus Alcantara > I've tested with the semver extension and it seems to work fine with > this patch. Can you please check on your side to see if it's also > working? Hi Matheus, thanks for the patch, it does indeed work. diff --git a/src/backend/commands/extension.c b/src/backend/commands/extension.c index 180f4af9be3..d68efd59118 100644 --- a/src/backend/commands/extension.c +++ b/src/backend/commands/extension.c @@ -376,6 +376,14 @@ get_extension_control_directories(void) /* Substitute the path macro if needed */ mangled = substitute_path_macro(piece, "$system", system_dir); + + /* + * Append "extension" suffix in case is a custom extension control + * path. + */ + if (strcmp(piece, "$system") != 0) + mangled = psprintf("%s/extension", mangled); This would look prettier if it was something like mangled = substitute_path_macro(piece, "$system", system_dir "/extension"); ... but I'm wondering if it wouldn't be saner if the control path should be stored without "extension" in that struct. Then opening the control file would be path + "extension/" + filename and the extra directory would be path + directory, without any on-the-fly stripping of trailing components. The extension_control_path GUC could also be adjusted to refer to the directory one level above the extension/foo.control location. + /* + * Assert that the control->control_dir end with /extension suffix so that + * we can replace with the value from control->directory. + */ + Assert(ctrldir_len >= suffix_len && + strcmp(control->control_dir + ctrldir_len - suffix_len, "extension") == 0); If control_dir is coming from extension_control_path, it might have a different suffix. Replace the Assert by elog(ERROR). (Or see above.) Christoph