Skip site navigation (1) Skip section navigation (2)

Re: search_path vs extensions

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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>
Subject: Re: search_path vs extensions
Date: 2009-05-28 07:36:44
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Hi all,

Seems the night has been providing lots of thoughs :)

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> Sure.  I think that having better search path management would be a
> wonderful thing; it would encourage people to use schema more in general.
> However, that doesn't mean that I think it should be part of the extensions
> design, or even a gating factor.

First, this thread allowed us to go from:
  "we don't know where to install extensions" 
  "we all agree that a specific pg_extension schema is a good idea, as
   soon as user is free not to use it at extension install time".

So you see, search_path and extensions are related and thinking about
their relationship will help design the latter.

> search_path_suffix = 'pg_modules, information_schema'
> search_path = 'main,web,accounts'
> ... would mean that any object named would search in
> main,web,accounts,pg_modules,information_schema.  This would be one way to
> solve the issue of having extra schema for extensions or other "utilities"
> in applications.

That really seems exactly to be what we're proposing with pre_ and post_
search_path components: don't change current meaning of search_path,
just give DBAs better ways to manage it. And now that you're leaning
towards a search_path suffix, don't you want a prefix too?


In response to


pgsql-hackers by date

Next:From: Andrew DunstanDate: 2009-05-28 08:08:50
Subject: Re: search_path vs extensions
Previous:From: Markus WannerDate: 2009-05-28 07:25:18
Subject: Re: PostgreSQL Developer meeting minutes up

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group