| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Daniel Farina <daniel(at)heroku(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Inline Extension |
| Date: | 2012-01-23 15:51:13 |
| Message-ID: | CA+Tgmob1rq7tfDMTrGWkE5VYhfET5Fh-XcE_oNrvTQTH1onjwQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jan 23, 2012 at 10:46 AM, Dimitri Fontaine
<dimitri(at)2ndquadrant(dot)fr> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2012-01-23 15:52:20 | Re: GUC_REPORT for protocol tunables was: Re: Optimize binary serialization format of arrays with fixed size elements |
| Previous Message | Robert Haas | 2012-01-23 15:49:16 | Re: basic pgbench runs with various performance-related patches |