Re: RFC: Additional Directory for Extensions - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: RFC: Additional Directory for Extensions
Date
Msg-id CAGRY4nypoaR_v3CiTyAROjYZ5Hm=S6L3MPQv3D1=L_CFNGy_LA@mail.gmail.com
Whole thread Raw
In response to Re: RFC: Additional Directory for Extensions  (Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>)
Responses Re: RFC: Additional Directory for Extensions
List pgsql-hackers
On Thu, 22 Aug 2024 at 21:00, Gabriele Bartolini
<gabriele.bartolini@enterprisedb.com> wrote:
> On Thu, 22 Aug 2024 at 09:32, Jelte Fennema-Nio <postgres@jeltef.nl> 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 degree that the feature should reserve wildcard
characters and require them to be escaped if they appear on a path, so
there's no BC break if it's added later.

On Thu, 22 Aug 2024 at 21:00, Gabriele Bartolini
<gabriele.bartolini@enterprisedb.com> wrote:
>
> Hi Jelte,
>
> On Thu, 22 Aug 2024 at 09:32, Jelte Fennema-Nio <postgres@jeltef.nl> 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 you could say:
>>
>> SET extension_search_path = /mnt/extensions/pg16/*
>>
>> To mean effectively the same as you're describing above.
>
>
> That'd be great. +1.
>
> --
> Gabriele Bartolini
> Vice President, Cloud Native at EDB
> enterprisedb.com



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?
Next
From: Craig Ringer
Date:
Subject: Re: RFC: Additional Directory for Extensions