From: | "David E(dot) Wheeler" <david(at)justatheory(dot)com> |
---|---|
To: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: RFC: Additional Directory for Extensions |
Date: | 2024-06-25 17:33:08 |
Message-ID: | 7B93D5E6-135F-4D7E-8DEB-1D17C4F0E204@justatheory.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jun 24, 2024, at 5:32 PM, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> wrote:
> Still, for the sake of completeness it might make sense to support
> this whole list in extension_destdir. (assuming it's easy to do)
It should be with the current patch, which just uses a prefix to paths in `pg_config`. So if SHAREDIR is set to /usr/share/postgresql/16 and extension_destdir is set to /mount/ext, then Postgres will look for files in /mount/ext/usr/share/postgresql/16. The same rule applies (or should apply) for all other pg_config directory configs and where the postmaster looks for specific files. And PGXS already supports installing files in these locations, thanks to its DESTDIR param.
(I don’t know how it works on Windows, though.)
That said, this is very much a pattern designed for RPM and Debian package management patterns, and not for actually installing and managing extensions. And maybe that’s fine for now, as it can still be used to address the immutability problems descried in the original post in this thread.
Ultimately, I’d like to figure out a way to more tidily organize installed extension files, but I think that, too, might be a separate thread.
Best,
David
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2024-06-25 17:35:44 | Re: New standby_slot_names GUC in PG 17 |
Previous Message | Andres Freund | 2024-06-25 17:10:26 | Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin |