Re: Inline Extension - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Inline Extension
Date
Msg-id CA+Tgmob1rq7tfDMTrGWkE5VYhfET5Fh-XcE_oNrvTQTH1onjwQ@mail.gmail.com
Whole thread Raw
In response to Re: Inline Extension  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: Inline Extension  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
On Mon, Jan 23, 2012 at 10:46 AM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Hmm, I don't think I like that design.  I think we should view this as
>> a way to embed the SQL and control files needed by the extension in
>> the server, rather than a separate thing called an inline extension.
>> If pg_dump is going to dump those files, it ought to dump them all,
>> not just some subset of them.
>
> Ok, but then, what about .so files?  Wouldn't it make sense to be able
> to ship also the executable modules needed, and if not, why not?

Sure, that would be as useful as any other part of this feature.  We'd
have to think carefully about how to make it secure, though: obviously
it's no good to let a non-superuser database owner install compiled C
code that gets loaded into the backend!

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: basic pgbench runs with various performance-related patches
Next
From: Robert Haas
Date:
Subject: Re: GUC_REPORT for protocol tunables was: Re: Optimize binary serialization format of arrays with fixed size elements