Re: Inline Extension - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Inline Extension
Date
Msg-id 20087.1327034931@sss.pgh.pa.us
Whole thread Raw
In response to Re: Inline Extension  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Inline Extension  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List 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 by date:

Previous
From: Greg Smith
Date:
Subject: Re: Vacuum rate limit in KBps
Next
From: Greg Smith
Date:
Subject: Re: Publish checkpoint timing and sync files summary data to pg_stat_bgwriter