On 16 October 2014 12:59, Stephen Frost <sfr...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
