Andrew Gierth <and...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
