Re: Modifying and solidifying contrib
От | Andrew Dunstan |
---|---|
Тема | Re: Modifying and solidifying contrib |
Дата | |
Msg-id | 45BE6ACC.6090204@dunslane.net обсуждение исходный текст |
Ответ на | Re: Modifying and solidifying contrib (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: Modifying and solidifying contrib
Re: Modifying and solidifying contrib |
Список | pgsql-hackers |
Bruce Momjian wrote: > Andrew Dunstan wrote: > >> Bruce Momjian wrote: >> >>> Keep in mind all contrib loads into public, and I don't remember any >>> namespace conflict issues in the past. >>> >>> >> That is beside the point. Of course there haven't been conflicts - >> precisely because a single group controls the whole lot. What I said was >> that we should behave as sane third party extension authors would, >> namely to use their own namespace to protect themselves from conflicts >> with other unknown extensions. It's called setting a good example or >> eating your own dog food. >> > > The problem I see controlling per-user search_path if +10 extensions are > instlalled, and you want them always to be available by default. > This suggests maybe we need to look at beefing up a few things. For example, an alias facility that provided a name in schema X for things in schema Y would help lots here. (You want everything visible? Just alias it in public.) ISTR such things in DB2, although it's now many years since I laid hands on it, so my memory could well be very faulty. Also, ability to append to the search path rather than just set it could help, as might ability to add names of non-existent schemas (which would be ignored at run time when found not to exist). cheers andrew
В списке pgsql-hackers по дате отправления: