* Simon Riggs (simon@2ndQuadrant.com) wrote:
> On 16 October 2014 12:59, Stephen Frost <sfrost@snowman.net> wrote:
> >> > LOGROTATE:
> >> > pg_rotate_logfile()
> >>
> >> Do we need one just for that?
> >
> > It didn't seem to "belong" to any others and it's currently limited to
> > superuser but useful for non-superusers, so I would argue 'yes'. Now,
> > another option (actually, for many of these...) would be to trust in our
> > authorization system (GRANT EXECUTE) and remove the explicit superuser
> > check inside the functions, revoke EXECUTE from public, and tell users
> > to GRANT EXECUTE to the roles which should be allowed.
>
> Seems like OPERATOR would be a general description that could be
> useful elsewhere.
Ok.. but what else? Are there specific functions which aren't covered
by these role attributes which should be and could fall into this
category? I'm not against the idea of an 'operator' role, but I don't
like the idea that it means 'logrotate, until we figure out some other
thing which makes sense to put into this category'. For one thing, this
approach would mean that future version which add more rights to the
'operator' role attribute would mean that upgrades are granting rights
which didn't previously exist..
> > There was a suggestion raised (by Robert, I believe) that we store these
> > additional role attributes as a bitmask instead of individual columns.
> > I'm fine with either way, but it'd be a backwards-incompatible change
> > for anyone who looks at pg_authid. This would be across a major version
> > change, of course, so we are certainly within rights to do so, but I'm
> > also not sure how much we need to worry about a few bytes per pg_authid
> > row; we still have other issues if we want to try and support millions
> > of roles, starting with the inability to partition catalogs..
>
> I assumed that was an internal change for fast access.
We could make it that way by turning pg_authid into a view and using a
new catalog table for roles instead (similar to what we did with
pg_user ages ago when we added roles), but that feels like overkill to
me.
> An array of role attributes would be extensible and more databasey.
Hrm. Agreed, and it would save a bit of space for the common case where
the user hasn't got any of these attributes, though it wouldn't be as
efficient as a bitmap.
For my part, I'm not really wedded to any particular catalog
representation. Having reviewed the various superuser checks, I think
there's a few more role attributes which could/should be added beyond
the ones listed, but I don't think we'll ever get to 64 of them, so a
single int64 would work if we want the most compact solution.
Thanks!
Stephen