Re: search_path vs extensions

Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)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