Re: search_path vs extensions

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: search_path vs extensions
Дата
Msg-id 603c8f070905291426o16be7dcdx6a4e77f1cd530806@mail.gmail.com
обсуждение исходный текст
Ответ на Re: search_path vs extensions  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: search_path vs extensions  (Greg Stark <stark@enterprisedb.com>)
Re: search_path vs extensions  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-hackers
On Fri, May 29, 2009 at 4:49 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Greg Stark <stark@enterprisedb.com> writes:
>> I'm actually not sure if we should allow extensions to be installed
>> into separate schemas.
>
> It's starting to seem that best practice is to install "public"
> functions/etc into a common schema and "private" objects into an
> extension-specific schema.  The main problem with that from an extension
> author's point of view is the need to explicitly qualify all references
> to private objects, since they won't be in the search path.  Which is
> tedious, but doable.

This sounds quite horrid to me.  The way programming languages solve
this problem is they have a flag that either makes certain names not
visible from other namespaces, or they provide explicit control over
which names get exported.  Requiring the extension author to split up
the objects between two different hard-coded namespaces with schema
qualifications on every reference sounds like an unmanageable mess.

Of course we have no notion of exporting or importing names at all.
Maybe we should.  But I'm still of the opinion that this entire
discussion is a tangent.

...Robert


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Hannu Krosing
Дата:
Сообщение: Re: Python 3.0 does not work with PL/Python
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Testing of parallel restore with current snapshot