Re: search_path vs extensions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: search_path vs extensions
Date
Msg-id 18218.1243458872@sss.pgh.pa.us
Whole thread Raw
In response to Re: search_path vs extensions  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: search_path vs extensions  ("David E. Wheeler" <david@kineticode.com>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> Another way of handling this might be to provide for prepending or 
> appending to the search path (or even for removing items from it).

I was just about to raise that as a requirement.  Some folks on this
list might recognize the following coding pattern:
create schema rhn_channel;
--make rhn_channel be the default creation schemaupdate pg_settings set setting = 'rhn_channel,' || setting where name
='search_path';
 
... create a bunch of objects in schema rhn_channel ...
-- restore the original settingupdate pg_settings set setting = overlay( setting placing '' from 1 for
(length('rhn_channel')+1)) where name = 'search_path';
 

I agree that a nicer way to do that would be good.

>     alter database foo set search_path = '+bar, baz'; -- append
>     alter database foo set search_path = 'bar, baz+'; -- prepend

... but that ain't it :-(.  SET should mean SET, not "do something magic".
Particularly in ALTER DATABASE/ALTER USER, whose execution order
relative to other stuff isn't especially well defined.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: A couple of regression test anomalies
Next
From: Bruce Momjian
Date:
Subject: Re: New trigger option of pg_standby