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

From Robert Haas
Subject Re: [PATCH] SET search_path += octopus
Date
Msg-id CA+TgmoajtKgqJcW30vsP0n+QhCPUAeRb5rbjc6WDAna9q-vnPg@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] SET search_path += octopus  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] SET search_path += octopus  (Andres Freund <andres@anarazel.de>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] SET search_path += octopus
Next
From: Robert Haas
Date:
Subject: Re: Hash support for row types