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.
> 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.
An array of role attributes would be extensible and more databasey.
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services