Re: search_path vs extensions
От | Andrew Dunstan |
---|---|
Тема | Re: search_path vs extensions |
Дата | |
Msg-id | 4A1DA9F9.1020003@dunslane.net обсуждение исходный текст |
Ответ на | Re: search_path vs extensions (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
Ответы |
Re: search_path vs extensions
|
Список | pgsql-hackers |
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. > > 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.) > Another way of handling this might be to provide for prepending or appending to the search path (or even for removing items from it). examples - something like: alter database foo set search_path = '+bar, baz'; -- append alter database foo set search_path = 'bar, baz+'; -- prepend cheers andrew
В списке pgsql-hackers по дате отправления: