Re: Extensions and 9.2

On Tue, Dec 20, 2011 at 10:01 AM, Dimitri Fontaine
<dimitri(at)2ndquadrant(dot)fr> wrote:
> 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).

Personally, I hate patches that do more than one thing. For me, the
time required to verify a patch goes as about O(n^2) in its size.
Furthermore, putting more than one feature into a patch means that it
has to be rejected (or revised by the committer) if any one of those
features looks half-baked. I can't speak to the preferences of any
other contributor.

>  - 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.

Who creates this list?

If the answer is "the superuser", then why not just let them create a
suitable SECURITY DEFINER function if they are so inclined, wrapping
CREATE EXTENSION? We've occasionally had requests for "DDL
permissions" so that you could, for example, grant a given user the
right to ANALYZE a table (but nothing else). But it's not entirely
clear to me that it's worth doing that. Assuming the command in
question can be stuffed inside a function, the most you're gaining is
a little notational convenience, and I'm not convinced it's worth
building the amount of infrastructure that this will require for that.

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