Re: search_path vs extensions
От | David E. Wheeler |
---|---|
Тема | Re: search_path vs extensions |
Дата | |
Msg-id | D2A40358-F5F0-4AD9-BAB3-265F17037A88@kineticode.com обсуждение исходный текст |
Ответ на | Re: search_path vs extensions (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
Список | pgsql-hackers |
On May 27, 2009, at 1:49 PM, 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. Right, which is why I was thinking about an interface to push schemas onto the front of the path. Or the end. > Obviously there are other possible solutions, but pretending there > isn't a problem will get nowhere. Yeah, it was just the splitting bit that seemed a bit much to me. > (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.) Okay, then maybe it's the names of the paths in Dimitri's suggestion that were confusing me. prepend_search_path and append_search_path, or something like that, might be better. Best, David
В списке pgsql-hackers по дате отправления: