Re: Additional role attributes && superuser review - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Additional role attributes && superuser review
Date
Msg-id 20150307213935.GO29780@tamriel.snowman.net
Whole thread Raw
In response to Re: Additional role attributes && superuser review  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Additional role attributes && superuser review  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Peter, all,

* Peter Eisentraut (peter_e@gmx.net) wrote:
> Why are we not using roles and function execute privileges for this?

Alright, I've got an initial patch to do this for pg_start/stop_backup,
pg_switch_xlog, and pg_create_restore_point.  The actual backend changes
are quite small, as expected.  I'll add in the changes for the other
functions being discussed and adapt the documentation changes from
the earlier patch to make sense, but what I'd really appreciate are any
comments or thoughts regarding the changes to pg_dump (which are generic
to all of the function changes, of course).

I've added a notion of "the catalog schema" to pg_dump's internal
_namespaceinfo representation and then marked pg_catalog as being that
schema, as well as being a "dumpable" schema.  Throughout the
selectDumpable functions, I've made changes to only mark the objects in
the catalog as dumpable if they are functions.  I'm planning to look
into the extension and binary upgrade paths since I'm a bit worried
those may not work with this approach, but I wanted to get this out
there for at least an initial review as, if people feel this makes
things too ugly on the pg_dump side of things then we may want to
reconsider using the role attributes instead.

    Thanks!

        Stephen

Attachment

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: MD5 authentication needs help
Next
From: Gabriele Bartolini
Date:
Subject: Re: File based Incremental backup v8