Re: [PATCH] SET search_path += octopus

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [PATCH] SET search_path += octopus
Дата
Msg-id CA+TgmoajtKgqJcW30vsP0n+QhCPUAeRb5rbjc6WDAna9q-vnPg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] SET search_path += octopus  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [PATCH] SET search_path += octopus  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
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. 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.

FWIW, I also like the chosen syntax. I think it's more useful with
lists than with numbers, but maybe it's at least somewhat useful for
both. However, I do wonder if it'd be good to have a list-manipulation
syntax that allows you to control where the item gets inserted --
start and end being the cases that people would want most, I suppose.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [PATCH] SET search_path += octopus
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Hash support for row types