Skip site navigation (1) Skip section navigation (2)

Extensions and 9.2

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Extensions and 9.2
Date: 2011-12-20 15:01:33
Message-ID: m2d3bjz3qq.fsf@2ndQuadrant.fr (view raw, whole thread or download thread mbox)
Thread:
Lists: pgsql-hackers
Hi,

I've sent a first patch to improve extensions for 9.2, and intend on
sending a few more which I'll briefly present here. The point of this
email is to figure out how to branch the development, as all the patch
are going to conflict somehow (change the same parts of the code).

Either I develop them separately, with separate branches derived from
the master one, or I develop them as a stack, one on top of the other.
The difference is my ability to provide a patch for one of the features
that can be applied to master directly compared to how much time I have
to spend cooking one patch or the other (merge conflicts, etc).

If we are going to try and commit all of those for 9.2, then I can stack
them all atop of each other and have an easier development time.  Here's
the list:

 - extension features (requires / provides)

   as already sent, allows fine grained dependency management

 - SQL only extensions

   the goal here is to be able to install an SQL only extension without
   having to be granted OS shell access on the PostgreSQL server, or
   other arrangement allowing you to ship files (.control, .sql) in a
   place where usually only “root” has write access.

   meaning that the control file property that says “superuser = false”
   can be true for the distribution of extension too.

 - extension modules

   the goal here is to be able to list all the modules that are loaded
   by an extension — the install script will install all functions and
   will be loading all related .so, it's easy enough to keep track of
   them at creating_extension time and “register” that module list.

   that helps with systems auditing when you're called to understand a
   crash after the fact. Of course even better would be to only allow
   loading modules that as part of extensions, and to be able to list
   implemented hooks (and which extension is implementing which hook),
   but that would/could be some follow-up patches.

 - extension whitelisting

   the goal here is to grant non superuser to install extensions from a
   restricted list, introducing a specific “sudo” like behavior when the
   extension is implemented in C or some other non trusted language.

   that could be easily done with the current command trigger patch and
   a trigger procedure that is security definer, and doesn't need the
   parsetree at all, but that could easily drift away from 9.2, so maybe
   a specific implementation would be better here

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

Responses

pgsql-hackers by date

Next:From: Nikhil SontakkeDate: 2011-12-20 15:03:33
Subject: Re: Review: Non-inheritable check constraints
Previous:From: Nikhil SontakkeDate: 2011-12-20 14:39:38
Subject: Re: Review: Non-inheritable check constraints

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group