Re: [PATCH] SET search_path += octopus - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [PATCH] SET search_path += octopus
Date
Msg-id 20201020192435.wux6cq3bvna3mcvs@alap3.anarazel.de
Whole thread Raw
In response to Re: [PATCH] SET search_path += octopus  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [PATCH] SET search_path += octopus
List pgsql-hackers
Hi,

On 2020-10-20 14:39:42 -0400, Robert Haas wrote:
> On Tue, Oct 20, 2020 at 2:34 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> > On 2020-Oct-20, Tom Lane wrote:
> > > and the fact that we've gone twenty-odd years without similar
> > > previous proposals doesn't speak well for it being really useful.
> >
> > Actually, there's at least two threads about this:
> >
> > https://postgr.es/m/flat/86d2ceg611.fsf@jerry.enova.com
> > https://postgr.es/m/flat/74af1f60-34af-633e-ee8a-310d40c741a7%402ndquadrant.com
> 
> Yeah, I think this is clearly useful.

The proposal in this thread doesn't really allow what those mails
request. It explicitly just adds SET += to SQL, *not* to the config
file.


> ALTER SYSTEM
> shared_preload_libraries += direshark seems like a case with a lot of
> obvious practical application, and adding things to search_path seems
> compelling, too.

As far as I understand what the proposal does, if you were to do do an
ALTER SYSTEM like you do, it'd actually write an "absolute"
shared_preload_libraries value to postgresql.auto.conf. So if you then
subsequently modified the shared_preload_libraries in postgresql.conf
it'd be overwritten by the postgresql.auto.conf value, not "newly"
appended to.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Support for NSS as a libpq TLS backend
Next
From: Justin Pryzby
Date:
Subject: Re: CREATE TABLE .. PARTITION OF fails to preserve tgenabled for inherited row triggers