| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Dumping an Extension's Script |
| Date: | 2012-12-05 21:02:22 |
| Message-ID: | 12591.1354741342@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2012-12-05 21:16:52 +0100, Dimitri Fontaine wrote:
>> Now if we can't fix the executable files situation, what about making
>> the C coded extensions not require an executable anymore? I'm thinking
>> about studying what it would take exactly to write a PL/C where the
>> PostgreSQL backend would basically compile the embedded C code at CREATE
>> FUNCTION time and store bytecode or binary in the probin column.
>>
>> So, we're talking about a PL/C language, in-core or extension, where you
>> could define say hstore without shipping any executable binary. Yeah,
>> I'm crazy that way. Now I'll get back to the main thread
> Imo thats not a sensible thing to pursue.
That would be another thing that Red Hat would refuse to ship, as would
any other distro with an ounce of concern about security. But in any
case there's no way that we could implement it portably.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2012-12-05 21:15:38 | Re: PITR potentially broken in 9.2 |
| Previous Message | Dimitri Fontaine | 2012-12-05 20:49:11 | Re: Dumping an Extension's Script |