| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
| Cc: | "David E(dot) Wheeler" <david(at)kineticode(dot)com>, 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 21:00:41 |
| Message-ID: | 4A1DA9F9.1020003@dunslane.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
>
> Obviously there are other possible solutions, but pretending there
> isn't a problem will get nowhere.
>
> (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.)
>
Another way of handling this might be to provide for prepending or
appending to the search path (or even for removing items from it).
examples - something like:
alter database foo set search_path = '+bar, baz'; -- append
alter database foo set search_path = 'bar, baz+'; -- prepend
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-05-27 21:04:10 | Re: search_path vs extensions |
| Previous Message | Peter Eisentraut | 2009-05-27 21:00:21 | Re: [PATCH] plpythonu datatype conversion improvements |