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

Re: search_path vs extensions

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: search_path vs extensions
Date: 2009-05-27 08:50:00
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

"David E. Wheeler" <david(at)kineticode(dot)com> writes:
> On May 25, 2009, at 2:16 AM, Dimitri Fontaine wrote:
>> Proposal: pg_extension, a new dedicated system schema for extensions
> I like this, although I'd want to be able, as a user, to override that
> default and tell an extension to install in some other schema. That  would
> allow me to immediately overcome conflicts, and to organize my  extensions
> if I want, rather than throw them all in one place.

The moment you're adding specific schemas where to put extensions into,
you have to adapt your search_path. Some applications already have to
manage search_path for their own needs, so we're trying to avoid having
those people to care about extensions schemas and application schema at
the same time.

It could even not be the same people caring about those search_path

>> Proposal: Separate search_path into components: pre_search_path,
>>  search_path, post_search_path
> I don't follow this at all. How to the three components effect behavior? And
> what does this mean for where extensions are installed  in schemas?

This proposal tries to solve previous one limitations. It's very good in
the typical case when you want each extension to be installed in one (or
more) schemas but don't want to have the application to care about it.
Then you add your extensions schemas into pre_search_path and
application schemas into search_path, so that the application doesn't
have to manage pre_search_path.

Now it could be that your application is historically using the same
function names as some extension you're now adding to the server, and
you want to control which function is called when not schema
qualified. So you have the post_search_path to play with too.

The idea being that application developpers will maintain search_path
for the application schemas (and this search_path can vary depending on
the application role which connects to the database, of course), and the
DBA team will make extensions available transparently to the application
by adding the extension's schemas in either pre_search_path or

I hope I've added clarity to the point, rather than only some extra
verbosity... :)


In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2009-05-27 08:55:04
Subject: Re: Synchronous replication: Admin command forreplication_timeout_action
Previous:From: Simon RiggsDate: 2009-05-27 08:46:49
Subject: Re: survey of WAL blocksize changes

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