Re: search_path vs extensions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
Subject: Re: search_path vs extensions
Date: 2009-05-27 21:14:32
Message-ID: 18218.1243458872@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)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 schema
update pg_settings set setting = 'rhn_channel,' || setting where name = 'search_path';

... create a bunch of objects in schema rhn_channel ...

-- restore the original setting
update 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2009-05-27 21:16:07 Re: New trigger option of pg_standby
Previous Message Peter Eisentraut 2009-05-27 21:09:03 Re: A couple of regression test anomalies