* Tom Lane (t...@sss.pgh.pa.us) wrote: > Noah Misch <n...@leadboat.com> writes: > > On Thu, Nov 13, 2014 at 08:24:36PM -0500, Stephen Frost wrote: > >> Agreed. I'll take care of both and we'll make sure the new role > >> attributes being added will do the same for upgrades also. > > > That would make pg_dumpall less faithful for every role other than the > > bootstrap superuser, a net loss. It would be defensible to do this for > > BOOTSTRAP_SUPERUSERID only. > > Huh? It seems difficult to argue that it's "less faithful" to do this > when the previous version didn't have the concept at all.
I believe what Noah is pointing out is that we'll end up adding
attributes which weren't there already for superusers created by users.
You're correct that we currently enable all attributes for the bootstrap
superuser and therefore a dump/restore upgrade looks different from an
initdb, unless the dump includes all new attributes for the bootstrap
superuser.
There's a couple ways to address this-
Stop enabling all the role attribute bits for the bootstrap superuser,
in which case it'd look a lot more like other superusers that a user
might create (at least, in my experience, no one bothers to set the role
attributes beyond superuser in real environments).
or
Reflect actual capability in what is viewed through the catalog. This
might actually dovetail nicely with the role attribute representation
change which is also being discussed, were we to make pg_authid a view
which called 'has_rolX_privilege' to get the value for each attribute.
What's actually in the bitmask might end up being different, but at
least what's seen in pg_authid (and hopefully for all client tools)
would make sense. Of course, this also has the downside that if the
superuser bit is removed later, we'd revert to whatever is actually in
the catalog for the user and that'd potentially be different for the
bootstrap superuser vs. user-created superusers.
Personally, I'm leaning towards the first as it's less clutter in the
output of psql. If we add the role attributes proposed and continue to
enable all of them explicitly for the bootstrap superuser, the
'Attributes' column is going to get mighty wide. I don't really see the
explicit list of attributes as helping de-mystify what is going on for
users as it's akin to root anyway- doing an 'ls' as root doesn't show
all the file permissions based on what root can do.
Thanks!
Stephen
signature.asc
Description: Digital signature
