Re: search_path vs extensions
От | Dimitri Fontaine |
---|---|
Тема | Re: search_path vs extensions |
Дата | |
Msg-id | 8763fl4r1v.fsf@hi-media-techno.com обсуждение исходный текст |
Ответ на | Re: search_path vs extensions (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: search_path vs extensions
Re: search_path vs extensions |
Список | pgsql-hackers |
Hi all, Seems the night has been providing lots of thoughs :) Josh Berkus <josh@agliodbs.com> writes: > Sure. I think that having better search path management would be a > wonderful thing; it would encourage people to use schema more in general. > > However, that doesn't mean that I think it should be part of the extensions > design, or even a gating factor. First, this thread allowed us to go from: "we don't know where to install extensions" to: "we all agree that a specific pg_extension schema is a good idea, as soon as user is free not to use it at extensioninstall time". So you see, search_path and extensions are related and thinking about their relationship will help design the latter. > search_path_suffix = 'pg_modules, information_schema' > search_path = 'main,web,accounts' > > ... would mean that any object named would search in > main,web,accounts,pg_modules,information_schema. This would be one way to > solve the issue of having extra schema for extensions or other "utilities" > in applications. That really seems exactly to be what we're proposing with pre_ and post_ search_path components: don't change current meaning of search_path, just give DBAs better ways to manage it. And now that you're leaning towards a search_path suffix, don't you want a prefix too? Regards, -- dim
В списке pgsql-hackers по дате отправления: