>>>>> "David" == "David E Wheeler" <da...@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 care about 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) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
