On Tue, Dec 20, 2011 at 10:01 AM, Dimitri Fontaine <dimi...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
