Re: search_path vs extensions - Mailing list pgsql-hackers

From David E. Wheeler
Subject Re: search_path vs extensions
Date
Msg-id D2A40358-F5F0-4AD9-BAB3-265F17037A88@kineticode.com
Whole thread Raw
In response to Re: search_path vs extensions  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
List pgsql-hackers
On May 27, 2009, at 1:49 PM, Andrew Gierth wrote:

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

Right, which is why I was thinking about an interface to push schemas  
onto the front of the path. Or the end.

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

Yeah, it was just the splitting bit that seemed a bit much to me.

> (Setting the search path using a function or sql statement _after_
> connecting was not an option; it would have confused the connection
> persistance layer, which needed different parameters to tell the
> connections apart.)

Okay, then maybe it's the names of the paths in Dimitri's suggestion  
that were confusing me. prepend_search_path and append_search_path, or  
something like that, might be better.

Best,

David


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: A couple of gripes about the gettext plurals patch
Next
From: Dawid Kuroczko
Date:
Subject: Re: search_path vs extensions