Re: search_path vs extensions
От | Josh Berkus |
---|---|
Тема | Re: search_path vs extensions |
Дата | |
Msg-id | 4A1DE25C.6000301@agliodbs.com обсуждение исходный текст |
Ответ на | Re: search_path vs extensions (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: search_path vs extensions
Re: search_path vs extensions |
Список | pgsql-hackers |
Tom, > Well, we could certainly take that attitude and eliminate all this > hassle ;-). However, I think that more-flexible search path handling > might have other uses, so I don't see any reason not to think about it. 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. For example, I could see these kinds of settings: search_path_override (suset) would set all users to a specific search path and raise an error at any set search_path attempts. This would be mainly for secure applications. search_path_suffix (suset) would append a certain set of schema to the end of the search path regardless of what else the user put in, e.g.: 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. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com
В списке pgsql-hackers по дате отправления: