Re: search_path vs extensions

>>>>> "David" == "David E Wheeler" <david@kineticode.com> writes:
>> The moment you're adding specific schemas where to put extensions>> into, you have to adapt your search_path. Some
applications>>already have to manage search_path for their own needs, so we're>> trying to avoid having those people to
careabout extensions>> schemas and application schema at the same time.
 
David> That doesn't seem like much of a problem to me.

Unfortunately, the fact that something doesn't seem like much of a
problem to you doesn't actually make it less of a problem.

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

-- 
Andrew (irc:RhodiumToad)