Re: search_path vs extensions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: search_path vs extensions
Date
Msg-id 18022.1243458250@sss.pgh.pa.us
Whole thread Raw
In response to Re: search_path vs extensions  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: search_path vs extensions  (Josh Berkus <josh@agliodbs.com>)
Re: search_path vs extensions  (Dimitri Fontaine <dfontaine@hi-media.com>)
List pgsql-hackers
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> Splitting up search_path is something I've been thinking about for a
> while (and threw out on IRC as a suggestion, which is where Dimitri
> got it); it was based on actual experience running an app that set the
> search path in the connection parameters in order to select which of
> several different schemas to use for part (not all) of the data.  When
> setting search_path this way, there is no way to set only part of it;
> the client-supplied value overrides everything.

> Obviously there are other possible solutions, but pretending there
> isn't a problem will get nowhere.

I agree that some more flexibility in search_path seems reasonable,
but what we've got at the moment is pretty handwavy.  Dimitri didn't
suggest what the uses of the different parts of a three-part path
would be, and also failed to say what the implications for the default
creation namespace would be, as well as the existing special handling
of pg_temp and pg_catalog.  That stuff all works together pretty
closely; it'd be easy to end up making it less usable not more so.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: search_path vs extensions
Next
From: Zdenek Kotala
Date:
Subject: Re: problem with plural-forms