Re: search_path vs extensions - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: search_path vs extensions
Date
Msg-id 87tz379bgn.fsf@hi-media-techno.com
Whole thread Raw
In response to Re: search_path vs extensions  ("David E. Wheeler" <david@kineticode.com>)
Responses Re: search_path vs extensions  ("David E. Wheeler" <david@kineticode.com>)
List pgsql-hackers
Hi,

"David E. Wheeler" <david@kineticode.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
parts.


>> 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
post_search_path.

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

Regards,
-- 
dim


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: survey of WAL blocksize changes
Next
From: Simon Riggs
Date:
Subject: Re: Synchronous replication: Admin command for replication_timeout_action