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: 87tz379bgn.fsf@hi-media-techno.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

"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
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2009-05-27 08:55:04 Re: Synchronous replication: Admin command for replication_timeout_action
Previous Message Simon Riggs 2009-05-27 08:46:49 Re: survey of WAL blocksize changes