On Apr 25, 2025, at 15:23, David E. Wheeler wrote:
> Thank you for the review. Here’s v3*.
V4 removes “/extension” from the end of the `extension_control_path` value.
Best,
David
v4-0001-Flesh-out-docs-for-the-prefix-make-variable.patch
Description: Binary data
signature.asc
Description:
On Apr 25, 2025, at 07:33, Christoph Berg wrote:
>
> Re: David E. Wheeler
>> +
>> +make install prefix=/etc/postgresql
>
> I'd use /usr/local/postgresql there. "/etc" is just wrong.
Thank you for the review. Here’s v3*.
Best,
David
* Also reviewable as a GitHub PR[1].
[1]: https://github.co
Re: David E. Wheeler
> +
> +make install prefix=/etc/postgresql
I'd use /usr/local/postgresql there. "/etc" is just wrong.
> +
> +This will install the control SQL files into
> +/etc/postgresql/share and shared modules into
> +/etc/postgresql/lib. If the prefix does not
> +include
On Mar 19, 2025, at 13:29, David E. Wheeler wrote:
> I think this should at least be documented, but generally feels unexpected to
> me. I’ve attached a patch that fleshes out the docs, along with an example of
> setting `extension_control_path` and `dynamic_library_path` to use the
> location
On Wed, Mar 19, 2025 at 3:56 PM Tom Lane wrote:
>
> Peter Eisentraut writes:
> > Committed that, thanks.
>
> Buildfarm member snakefly doesn't like this too much. Since no other
> animals have failed, I guess it must be about local conditions on
> that machine, but the report is pretty opaque:
>
Matheus Alcantara writes:
> (Not sure if we should also improve the message to make the test failure less
> opaque?)
Yeah, I was wondering how to do that. The earlier tests in that
script show the whole row from pg_available_extensions, not just a
bool ... but that doesn't help if the problem is
Peter Eisentraut writes:
> Committed that, thanks.
Buildfarm member snakefly doesn't like this too much. Since no other
animals have failed, I guess it must be about local conditions on
that machine, but the report is pretty opaque:
# +++ tap check in src/test/modules/test_extensions +++
# F
On Thu, Mar 20, 2025 at 7:38 PM Andrew Dunstan wrote:
>>>
>>> Buildfarm member snakefly doesn't like this too much. Since no other
>>> animals have failed, I guess it must be about local conditions on
>>> that machine, but the report is pretty opaque:
>>>
>>> # +++ tap check in src/test/modules/t
On 2025-03-21 Fr 12:42 PM, Tom Lane wrote:
Matheus Alcantara writes:
On Thu, Mar 20, 2025 at 7:38 PM Andrew Dunstan wrote:
(wondering if this another of these cases where the "path includes postgres"
thing bites us, and we're looking in the wrong place)
Nope, testing shows it's not that, so
On Mar 21, 2025, at 17:52, Matheus Alcantara wrote:
> Did you miss to attach the patch?
No. You can see it in the archive[1]. Direct link[2].
> Maybe we could make the "extension" part of the extension control path
> explicitly, like Peter has mentioned in his first patch version [1]?.
> If "d
Hi David, thanks for testing!
On Wed, Mar 19, 2025 at 2:29 PM David E. Wheeler wrote:
>
> First thing I notice is that prefix= uses the magic to insert
> “postgresql” into the path if it’s not already there:
>
> ``` console
> ❯ make PG_CONFIG=~/dev/c/postgres/pgsql-devel/bin/pg_config
> prefix=/
On 2025-03-21 Fr 11:52 AM, Matheus Alcantara wrote:
On Thu, Mar 20, 2025 at 7:38 PM Andrew Dunstan wrote:
Buildfarm member snakefly doesn't like this too much. Since no other
animals have failed, I guess it must be about local conditions on
that machine, but the report is pretty opaque:
# +
Matheus Alcantara writes:
> On Thu, Mar 20, 2025 at 7:38 PM Andrew Dunstan wrote:
>>> (wondering if this another of these cases where the "path includes
>>> postgres" thing bites us, and we're looking in the wrong place)
>> Nope, testing shows it's not that, so I am rather confused about what w
On 2025-03-20 Th 10:53 AM, Andrew Dunstan wrote:
On 2025-03-19 We 2:55 PM, Tom Lane wrote:
Peter Eisentraut writes:
Committed that, thanks.
Buildfarm member snakefly doesn't like this too much. Since no other
animals have failed, I guess it must be about local conditions on
that machine, b
On 2025-03-19 We 2:55 PM, Tom Lane wrote:
Peter Eisentraut writes:
Committed that, thanks.
Buildfarm member snakefly doesn't like this too much. Since no other
animals have failed, I guess it must be about local conditions on
that machine, but the report is pretty opaque:
# +++ tap check in
Peter Eisentraut writes:
> On 19.03.25 20:25, Matheus Alcantara wrote:
>> On Wed, Mar 19, 2025 at 3:56 PM Tom Lane wrote:
>>> Buildfarm member snakefly doesn't like this too much.
> I was able to reproduce the problem from scratch using:
> ./configure ...
> make # no contrib
> make -C src/test
On 19.03.25 20:25, Matheus Alcantara wrote:
On Wed, Mar 19, 2025 at 3:56 PM Tom Lane wrote:
Peter Eisentraut writes:
Committed that, thanks.
Buildfarm member snakefly doesn't like this too much. Since no other
animals have failed, I guess it must be about local conditions on
that machine,
On Mar 19, 2025, at 02:42, Peter Eisentraut wrote:
> Committed that, thanks.
🎉
I’ve been meaning to test the patch again, so here goes.
First thing I notice is that prefix= uses the magic to insert “postgresql” into
the path if it’s not already there:
``` console
❯ make PG_CONFIG=~/dev/c/pos
Re: Peter Eisentraut
> Committed that, thanks.
Awesome, thanks!
It works perfectly for the Debian "test extension packages at build
time" use case, replacing our old extension_destdir patch.
PKGARGS="--pgoption
extension_control_path=$PWD/debian/$PACKAGE/usr/share/postgresql/$v/extension:\$syst
Thanks everyone for making this happen.
Ciao,
Gabriele
On Wed, 19 Mar 2025 at 07:42, Peter Eisentraut wrote:
> 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
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
On Tue, Mar 11, 2025 at 12:59 PM Peter Eisentraut wrote:
> Yes, that structure looks ok. But you can remove one level of block in
> get_extension_control_directories().
>
Sorry, missed during debugging. Fixed
> I found a bug that was already present in my earlier patch versions:
>
> @@ -423,7 +4
On 10.03.25 21:25, Matheus Alcantara wrote:
On Thu, Mar 6, 2025 at 10:46 AM Peter Eisentraut wrote:
This looks very good to me. I have one issue to point out: The logic
in get_extension_control_directories() needs to be a little bit more
careful to align with the rules in find_in_path(). For
Hi,
Thanks for reviewing and suggestions!
On Thu, Mar 6, 2025 at 10:46 AM Peter Eisentraut wrote:
> This looks very good to me. I have one issue to point out: The logic
> in get_extension_control_directories() needs to be a little bit more
> careful to align with the rules in find_in_path().
On 03.03.25 19:45, Matheus Alcantara wrote:
Hi, attached a new v5 with some minor improvements on TAP tests:
- Add a proper test name for all test cases
- Add CREATE EXTENSION command execution
- Change the assert on pg_available_extensions and
pg_available_extension_versions to validate the
Hi, attached a new v5 with some minor improvements on TAP tests:
- Add a proper test name for all test cases
- Add CREATE EXTENSION command execution
- Change the assert on pg_available_extensions and
pg_available_extension_versions to validate the row content
Also rebased with master
--
Math
On Mar 3, 2025, at 10:05, David E. Wheeler wrote:
> Very nice writeup, thank you. Makes me wish for the bandwidth to get back to
> and start refining the PGXN OCI RFC
Forgot to link to the POC[1]. The RFC[2] is not OCI-specific, but the POC
demonstrates the “full content” version. Will likely
On Mar 3, 2025, at 08:39, Gabriele Bartolini
wrote:
> As promised, here is a blog article that provides more context and
> information about what this feature will mean in Kubernetes with
> CloudNativePG:
> https://www.gabrielebartolini.it/articles/2025/03/the-immutable-future-of-postgresql-e
As promised, here is a blog article that provides more context and
information about what this feature will mean in Kubernetes with
CloudNativePG:
https://www.gabrielebartolini.it/articles/2025/03/the-immutable-future-of-postgresql-extensions-in-kubernetes-with-cloudnativepg/
Thanks,
Gabriele
On
Hi everyone,
I have finally been able to test the patch in a Kubernetes environment with
CloudNativePG, thanks to Niccolò Fei and Marco Nenciarini, who created a
pilot patch for CloudNativePG (
https://github.com/cloudnative-pg/cloudnative-pg/pull/6546).
In the meantime, Kubernetes is likely addi
Hi
On Tue, Feb 25, 2025 at 5:29 PM Matheus Alcantara
wrote:
> Fixed on the attached v3.
>
After I've sent the v3 patch I noticed that the tests were failing on windows.
The problem was on TAP test that was using ":" as a separator on
extension_control_path and also the path was not being escaped
Thanks for reviewing!
On Tue, Feb 25, 2025 at 9:45 AM Andrew Dunstan wrote:
> I think your additions generally look good. We should be able to
> simplify this:
>
>
> +system_dir = psprintf("%s/extension", sharepath);
> +ecp = system_dir;
> +
> +if (strlen(Extension_control_path) == 0)
On 2025-02-24 Mo 8:33 AM, Matheus Alcantara wrote:
Hi,
On Thu, Dec 5, 2024 at 8:07 AM Peter Eisentraut wrote:
This patch is now complete enough for testing, I think. As I mentioned
earlier, I haven't updated pg_available_extensions() etc. to support the
path, but that shouldn't prevent some
Hi,
On Thu, Dec 5, 2024 at 8:07 AM Peter Eisentraut wrote:
>
> This patch is now complete enough for testing, I think. As I mentioned
> earlier, I haven't updated pg_available_extensions() etc. to support the
> path, but that shouldn't prevent some testing.
To help with this patch I'm attaching
Hi Andrew,
On Feb 4, 2025, at 15:34, Andrew Dunstan wrote:
>> I see. I confirm that works. Still, don’t all the other parameters work when
>> passed to any/all targets? Should this one have an extension-specific name?
>
> IDK, I don't understand what you think you're saying when you specify
>
On 2025-02-03 Mo 3:42 PM, David E. Wheeler wrote:
Hi Peter,
prefix= should only be set when running the "install" target, not when building
(make all).
I see. I confirm that works. Still, don’t all the other parameters work when
passed to any/all targets? Should this one have an extension-
Hi Peter,
> prefix= should only be set when running the "install" target, not when
> building (make all).
I see. I confirm that works. Still, don’t all the other parameters work when
passed to any/all targets? Should this one have an extension-specific name?
>> So I suspect the issue is that,
On 14.01.25 21:01, David E. Wheeler wrote:
I tried `prefix` with semver[3] and it did not work:
``` console
❯ make PG_CONFIG=~/dev/misc/postgres/pgsql-devel/bin/pg_config
prefix=/Users/david/pgsql-test
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement
-Werror=vla -We
Hello Peter & Co.
On Dec 5, 2024, at 06:07, Peter Eisentraut wrote:
> I've made a bit of progress on this patch, filled in some documentation and
> resolved some TODO markers. Also:
Finally getting around to reviewing this patch. Should it be considered part of
the previous patch[1] for pur
On 11.11.24 08:16, Peter Eisentraut wrote:
I implemented a patch along the lines Craig had suggested. It's a new
GUC variable that is a path for extension control files. It's called
extension_control_path, and it works exactly the same way as
dynamic_library_path. Except that the magic token
On Nov 20, 2024, at 04:05, Peter Eisentraut wrote:
> The path is only consulted if the specified name does not contain a slash.
> So if you do LOAD 'foo', the path is consulted, but if you do LOAD
> '$libdir/foo', it is not. The problem I'm describing is that most extensions
> use the latter
On 18.11.24 20:19, David E. Wheeler wrote:
- The biggest problem is that many extensions set in their control file
module_pathname = '$libdir/foo'
This disables the use of dynamic_library_path, so this whole idea of installing
an extension elsewhere won't work that way. The obvious solutio
Hi Peter,
Making another pass at this proposal, I’m a bit confused by this issue:
On Nov 12, 2024, at 09:44, David E. Wheeler wrote:
- The biggest problem is that many extensions set in their control file
module_pathname = '$libdir/foo'
This disables the use of dyna
On Nov 12, 2024, at 08:25, Peter Eisentraut wrote:
> No, you can also install them into a common directory and mount that one.
> For example, you install the extension at build time into
> /tmp/foo/{lib,share/extension}, you package that up as a disk image, mount it
> at /opt/extensions/myext
On 11.11.24 19:15, David E. Wheeler wrote:
In fact, most of the patch is refactoring the routines in dfmgr.c to not
hardcode dynamic_library_path but allow searching for any file in any path.
Once a control file is found, the other extension support files (script files
and auxiliary control f
On Nov 11, 2024, at 02:16, Peter Eisentraut wrote:
> I implemented a patch along the lines Craig had suggested.
Oh, nice, thank you.
> It's a new GUC variable that is a path for extension control files. It's
> called extension_control_path, and it works exactly the same way as
> dynamic_libr
I implemented a patch along the lines Craig had suggested. It's a new
GUC variable that is a path for extension control files. It's called
extension_control_path, and it works exactly the same way as
dynamic_library_path. Except that the magic token is called $system
instead of $libdir. In
{
"emoji": "❤️",
"version": 1
}
On Oct 10, 2024, at 13:20, Ebru Aydin Gol wrote:
> Thanks for your efforts, a secondary directory for extensions is a very
> useful feature.
>
> Is there any updates on the patch?
There haven't been, no, but your reply has chastened me! I’ve now started a
separate thread[1] proposing direct
Thanks for your efforts, a secondary directory for extensions is a very
useful feature.
Is there any updates on the patch?
-Ebru
On Thu, Aug 29, 2024 at 6:55 PM David E. Wheeler
wrote:
> On Aug 27, 2024, at 22:24, Craig Ringer
> wrote:
>
> > `pg_config` only cares about compile-time settings
On Aug 27, 2024, at 22:24, Craig Ringer wrote:
> `pg_config` only cares about compile-time settings, so I would not
> expect its output to change.
Right, of course that’s its original purpose, but extensions depend on it to
determine where to install extensions. Not just PGXS, but also pgrx and
On Wed, 28 Aug 2024 at 03:26, David E. Wheeler wrote:
> Right. ISTM it could complicate PGXS quite a bit. If we set, say,
>
> SET extension_search_path = $extsdir, /mnt/extensions/pg16,
> /mnt/extensions/pg16/gosuperfast/extensions;
>
> What should be the output of `pg_config --sharedir`?
`pg_co
On Aug 26, 2024, at 17:35, Craig Ringer wrote:
> This looks like a good suggestion to me, it would make the packaging,
> distribution and integration of 3rd party extensions significantly
> easier without any obvious large or long term cost.
Yes!
> Also PGXS, the windows extension build support
On Aug 27, 2024, at 04:56, Gabriele Bartolini
wrote:
> The extension image could follow a naming convention like this (order can be
> adjusted): `-- version>-(-)`. For example, `pgvector-16-0.7.4-bookworm-1` would
> represent the first image built in a repository for pgvector 0.7.4 for
> Post
Hi David,
Thanks for your email.
On Mon, 26 Aug 2024 at 16:07, David E. Wheeler
wrote:
> I would assume BINDIR, DOCDIR, HTMLDIR, PKGLIBDIR, MANDIR, SHAREDIR, and
> perhaps LOCALEDIR.
>
> But even if it’s just one or two, the only proper way an extension
> directory would work, IME, is to define
On Tue, 27 Aug 2024 at 02:07, David E. Wheeler wrote:
> On Aug 21, 2024, at 19:07, Craig Ringer wrote:
> But even if it’s just one or two, the only proper way an extension directory
> would work, IME, is to define a directory-based structure for extensions,
> where every file for an extension
Hi Hackers,
Apologies for the delay in reply; I’ve been at the XOXO Festival and almost
completely unplugged for the first time in ages. Happy to see this thread
coming alive, though. Thank you Gabriele, Craig, and Jelte!
On Aug 21, 2024, at 19:07, Craig Ringer wrote:
> So IMO this should be
On Fri, 23 Aug 2024 at 10:14, Craig Ringer
wrote:
> On Thu, 22 Aug 2024 at 21:00, Gabriele Bartolini
> wrote:
> > On Thu, 22 Aug 2024 at 09:32, Jelte Fennema-Nio wrote:
> >> SET extension_search_path = /mnt/extensions/pg16/*
> >
> > That'd be great. +1.
>
> Agreed, that'd be handy, but not worth
On Thu, 22 Aug 2024 at 21:00, Gabriele Bartolini
wrote:
> On Thu, 22 Aug 2024 at 09:32, Jelte Fennema-Nio wrote:
>> SET extension_search_path = /mnt/extensions/pg16/*
>
> That'd be great. +1.
Agreed, that'd be handy, but not worth blocking the underlying capability for.
Except possibly to the d
Hi Jelte,
On Thu, 22 Aug 2024 at 09:32, Jelte Fennema-Nio wrote:
> It looks like you want one directory per extension, so that list would
> get pretty long if you have multiple extensions. Maybe (as a follow up
> change), we should start to support a * as a wildcard in both of these
> GUCs. So y
Hi Craig,
On Thu, 22 Aug 2024 at 01:07, Craig Ringer
wrote:
> It's also very relevant for local development and testing.
>
Yep, which is the original goal of Christoph IIRC.
> It may be possible to weaken this restriction somewhat thanks to the
> upcoming
> https://kubernetes.io/blog/2024/08/
On Thu, 22 Aug 2024 at 01:08, Craig Ringer
wrote:
> SET extension_search_path = $extsdir,
> /mnt/extensions/pg16/postgis-vX.Y/extensions,
> /mnt/extensions/pg16/gosuperfast/extensions;
It looks like you want one directory per extension, so that list would
get pretty long if you have multiple
On Thu, 22 Aug 2024 at 08:00, Gabriele Bartolini
wrote:
>
> Hi everyone,
>
> Apologies for only starting to look into this now. Thanks, David, for pushing
> this forward.
100%. I've wanted this for some time but never had time to cook up a patch.
> I want to emphasize the importance of this p
On Tue, Jun 25, 2024 at 12:12:33PM +0200, Alvaro Herrera wrote:
> archive_command and so on: we could disable these too. Nathan did some
> work to implement those using dynamic libraries, so it shouldn't be too
> much of a loss; anything that is done with a shell script can also be
> done with a s
Hi everyone,
Apologies for only starting to look into this now. Thanks, David, for
pushing this forward.
I want to emphasize the importance of this patch for the broader adoption
of extensions in immutable container environments, such as those used by
the CloudNativePG operator in Kubernetes.
To
On Jun 25, 2024, at 18:31, David E. Wheeler wrote:
> For those who prefer a GitHub patch review experience, see this PR:
>
> https://github.com/theory/postgres/pull/3/files
Rebased and restored PGC_SUSET in the attached v5 patch, plus noted the
required privileges in the docs.
Best,
David
On Tue, 25 Jun 2024 at 19:33, David E. Wheeler wrote:
>
> On Jun 24, 2024, at 5:32 PM, Jelte Fennema-Nio 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, wh
On Wed, 26 Jun 2024 at 00:32, David E. Wheeler wrote:
> In other news, here’s an updated patch that expands the documentation to
> record that the destination directory is a prefix, and full paths should be
> used under it. Also take the opportunity to document the PGXS DESTDIR
> variable as th
On Jun 25, 2024, at 10:43 AM, Robert Haas wrote:
> If we want to work on making the sorts of changes that
> you're proposing, let's do it on a separate thread. It's not going to
> be meaningfully harder to move in that direction after some patch like
> this than it is today.
I appreciate this se
On Jun 24, 2024, at 5:32 PM, Jelte Fennema-Nio 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
On Tue, Jun 25, 2024 at 6:12 AM Alvaro Herrera wrote:
> Now, I'm not saying that this is an easy journey. But if we don't
> start, we're not going to get there.
I actually kind of agree with you. I think I've said something similar
in a previous email to the list somewhere. But I don't agree tha
On Tue, 25 Jun 2024 at 12:12, Alvaro Herrera wrote:
> They can mutilate the system catalogs: yes, they can TRUNCATE pg_type.
> So what? They've just destroyed their own ability to do anything else.
> The real issue here is that they can edit pg_proc to cause SQL function
> calls to call arbitrary
On 2024-Jun-24, Robert Haas wrote:
> Is "tighten up what the superuser can do" on our list of objectives?
> Personally, I think we should be focusing mostly, and maybe entirely,
> on letting non-superusers do more things, with appropriate security
> controls. The superuser can ultimately do anythi
Re: Nathan Bossart
> At first glance, the general idea seems reasonable to me. I'm wondering
> whether there is a requirement for this directory to be prepended or if it
> could be appended to the end. That way, the existing ones would take
> priority, which might be desirable from a security sta
On Mon, 24 Jun 2024 at 22:42, David E. Wheeler wrote:
> >> BINDIR
> >> DOCDIR
> >> HTMLDIR
> >> PKGINCLUDEDIR
> >> LOCALEDIR
> >> MANDIR
> >>
> >> I can imagine an extension wanting or needing to use any and all of these.
> >
> > Are these really all relevant to backend code?
>
> Oh I think so. Es
On Jun 24, 2024, at 17:17, Jelte Fennema-Nio wrote:
> If you want to only change $libdir during CREATE EXTENSION (or ALTER
> EXTENSION UPDATE), then why not just change it there. And really you'd
> only want to change it when creating an extension from which the
> control file is coming from exte
On Mon, 24 Jun 2024 at 18:11, Nathan Bossart wrote:
> At first glance, the general idea seems reasonable to me. I'm wondering
> whether there is a requirement for this directory to be prepended or if it
> could be appended to the end. That way, the existing ones would take
> priority, which migh
On Thu, 11 Apr 2024 at 19:52, David E. Wheeler wrote:
> I realize this probably isn’t going to happen for 17, given the freeze, but I
> would very much welcome feedback and pointers to address concerns about
> providing a second directory for extensions and DSOs. Quite a few people have
> talke
On Jun 24, 2024, at 4:28 PM, Robert Haas wrote:
> As long as the GUC is superuser-only, I'm not sure what else there is
> to do here. The only question is whether there's some reason to
> disallow this even from the superuser, but I'm not quite seeing such a
> reason.
I can switch it back from r
On Mon, Jun 24, 2024 at 3:37 PM David E. Wheeler wrote:
> I guess the question then is what security controls are appropriate for this
> feature, which after all tells the postmaster what directories to read files
> from. It feels a little outside the scope of a regular user to even be aware
>
On Jun 24, 2024, at 1:53 PM, Robert Haas wrote:
> Is "tighten up what the superuser can do" on our list of objectives?
> Personally, I think we should be focusing mostly, and maybe entirely,
> on letting non-superusers do more things, with appropriate security
> controls. The superuser can ultima
On Wed, Apr 3, 2024 at 3:13 AM Alvaro Herrera wrote:
> I support the idea of there being a second location from where to load
> shared libraries ... but I don't like the idea of making it
> runtime-configurable. If we want to continue to tighten up what
> superuser can do, then one of the things
On Thu, Apr 11, 2024 at 01:52:26PM -0400, David E. Wheeler wrote:
> I realize this probably isn´t going to happen for 17, given the freeze,
> but I would very much welcome feedback and pointers to address concerns
> about providing a second directory for extensions and DSOs. Quite a few
> people ha
On Apr 4, 2024, at 1:20 PM, David E. Wheeler wrote:
> I’ve added some docs based on your GUC description; updated patch attached.
Here’s a rebase.
I realize this probably isn’t going to happen for 17, given the freeze, but I
would very much welcome feedback and pointers to address concerns abo
On Apr 3, 2024, at 12:46 PM, Christoph Berg wrote:
> Thanks for bringing this up, I should have submitted this years ago.
> (The patch is originally from September 2020.)
That’s okay, it’s still 2020 in some ways. 😂
> I designed the patch to require a superuser to set it, so it doesn't
> matter
> Fwiw, I wrote this patch to solve the problem of testing extensions at
> build-time where the build process does not have write access to
> PGSHAREDIR. It solves that problem quite well, almost all PG
> extensions have build-time test coverage now (where there was
> basically 0 before).
Also, it
Re: David E. Wheeler
> > Yes, I like the suggestion to make it require a restart, which lets the
> > sysadmin control it and not limited to whatever the person who compiled it
> > thought would make sense.
>
> Here’s a revision of the Debian patch that requires a server start.
Thanks for bringi
On Apr 3, 2024, at 8:54 AM, David E. Wheeler wrote:
> Yes, I like the suggestion to make it require a restart, which lets the
> sysadmin control it and not limited to whatever the person who compiled it
> thought would make sense.
Here’s a revision of the Debian patch that requires a server st
On Apr 3, 2024, at 8:54 AM, David E. Wheeler wrote:
> Yes, I like the suggestion to make it require a restart, which lets the
> sysadmin control it and not limited to whatever the person who compiled it
> thought would make sense.
Or SIGHUP?
D
On Apr 3, 2024, at 3:57 AM, walt...@technowledgy.de wrote:
> I can also imagine that it would be very helpful in a container setup to be
> able to set an environment variable with this path instead of having to
> recompile all of postgres to change it.
Yes, I like the suggestion to make it requ
> On 3 Apr 2024, at 09:13, Alvaro Herrera wrote:
>
> On 2024-Apr-02, David E. Wheeler wrote:
>
>> That quotation comes from this Debian patch[2] maintained by Christoph
>> Berg. I’d like to formally propose integrating this patch into the
>> core. And not only because it’s overhead for package m
Alvaro Herrera:
I support the idea of there being a second location from where to load
shared libraries ... but I don't like the idea of making it
runtime-configurable. If we want to continue to tighten up what
superuser can do, then one of the things that has to go away is the
ability to load s
On 2024-Apr-02, David E. Wheeler wrote:
> That quotation comes from this Debian patch[2] maintained by Christoph
> Berg. I’d like to formally propose integrating this patch into the
> core. And not only because it’s overhead for package maintainers like
> Christoph, but because a number of use cas
Hackers,
In the Security lessons from liblzma thread[1], walther broached the subject of
an extension directory path[1]:
> Also a configurable directoy to look up extensions, possibly even to be
> changed at run-time like [2]. The patch says this:
>
>> This directory is prepended to paths when
94 matches
Mail list logo
