Re: Inline Extension

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Inline Extension
Дата
Msg-id 20087.1327034931@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Inline Extension  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Inline Extension  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Jan 19, 2012 at 3:42 PM, Dimitri Fontaine
>> I'm trying to open the extension facilities (versions being the first of
>> them, think \dx) to application PL code, and to hosted environments
>> where you're not granted access to the server's file system.

> I guess the question is: for what purpose?

> As you recognized in your original email, if the extension is inline,
> then the objects will need to be dumped, because a simple CREATE
> EXTENSION command is bound to fail.  But my understanding was that a
> major part of the reason - if not the entire reason - was to get
> pg_dump to emit CREATE EXTENSION bob instead of the component SQL
> commands.  If we take that away, what's the remaining benefit of
> packaging those objects inside an extension instead of just dumping
> them "loose" into the database?

Indeed, it seems like such a thing is not an extension at all anymore,
or at least it gives up many of the useful properties of extensions.

Given the entire lack of demand from the field for such a cut-down
concept of extension, I think we should not be in a hurry to introduce
it.  Maybe in a year or two when we have a clearer idea of how people
are actually using extensions, there will be a better argument for it.
Right now I'm afraid that we might foreclose our options for other
future extension features because these things would be incompatible
with such ideas.
        regards, tom lane


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

Предыдущее
От: Greg Smith
Дата:
Сообщение: Re: Vacuum rate limit in KBps
Следующее
От: Greg Smith
Дата:
Сообщение: Re: Publish checkpoint timing and sync files summary data to pg_stat_bgwriter