Re: Dumping an Extension's Script

Andres Freund <andres@2ndquadrant.com> writes:
> Maybe I am missing something, but you already can separate them per
> major version. You co-wrote the debian infrastructure to do so for some
> debian packages, so I am not sure what you mean here.

The debian infrastructure I've help building is all about compiling an
extension source package once and having as many binary artefacts as you
have major versions of PostgreSQL lying around.  So yes in debian you
can actually install such extensions at different on disk locations per
major version. Sorry for the confusion.

> Adding some *NON WRITABLE* per-cluster library directory doesn't seem to
> be as controversion as other suggestions.

Well, it means a per-initdb (user driven) location where to store binary
files, ask Tom what he thinks about that with his Red Hat Packager… Hat.

> On 2012-12-05 13:18:16 -0500, Tom Lane wrote:
>> I think you're wasting your time to imagine that that case will ever be
>> "fixed".  Allowing the server to scribble on executable files would set
>> off all kinds of security alarm bells, and rightly so.  If Postgres ever
>> did ship with such a thing, I rather imagine that I'd be required to
>> patch it out of Red Hat releases (not that SELinux wouldn't prevent
>> it from happening anyway).

That part I did understand. I still can't be happy about it, but I won't
get back with any proposal where that's put into questions. That said,
while you're talking about it, what if it's an opt-in GUC?

>> I do see an argument for allowing SQL-only extensions to be installed
>> this way, since that doesn't allow the execution of anything the user
>> couldn't execute anyway.  There's no need to worry about anything except
>> control and script files though.
[…please make sure you're not drinking (coffee) before reading further…]

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.

I've stumbled accross more than one "dynamic code" or "retargetable
compiler" thing already, and several of those even have compatible
licences. Maybe the most promising ones are PL/LLVM or embeding the QEMU
code transformation code (a fork of the tcc compiler).

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…


Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support