Re: [PATCH] SET search_path += octopus

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: [PATCH] SET search_path += octopus
Дата
Msg-id 20201020192435.wux6cq3bvna3mcvs@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: [PATCH] SET search_path += octopus  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [PATCH] SET search_path += octopus  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Support for NSS as a libpq TLS backend
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: CREATE TABLE .. PARTITION OF fails to preserve tgenabled for inherited row triggers