From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
---|---|
To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
Subject: | Re: search_path vs extensions |
Date: | 2009-05-27 22:38:01 |
Message-ID: | D2A40358-F5F0-4AD9-BAB3-265F17037A88@kineticode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | David E. Wheeler | 2009-05-27 22:39:49 | Re: search_path vs extensions |
Previous Message | Tom Lane | 2009-05-27 21:54:32 | Re: A couple of gripes about the gettext plurals patch |