Re: Additional role attributes && superuser review

All,

> If we're going to change the catalog representation for the existing
> capabilities, I'd recommend that the first patch change the catalog
> representation and add the new syntax without adding any more
> capabilities; and then the second and subsequent patches can add
> additional capabilities.

Attached is an initial patch for review and discussion that takes a swing
at changing the catalog representation.

This patch includes:

* int64 (C) to int8 (SQL) mapping for genbki.
* replace all role attributes columns in pg_authid with single int64 column
named rolattr.
* update CreateRole and AlterRole to use rolattr.
* update all has_*_privilege functions to check rolattr.
* builtin SQL function 'has_role_attribute' that takes a role oid and text
name of the attribute as input and returns a boolean.

Items not currently addressed:

* New syntax - more discussion needs to occur around these potential
changes. Specifically, how would CREATE USER/ROLE be affected? I suppose
it is OK to keep it as WITH <attribute_or_capability>, though if ALTER ROLE
is modified to have ADD | DROP CAPABILITY for consistency would WITH
CAPABILITY <value,...>, make more sense for CREATE? At any rate, I think
there is obviously much more discussion that needs to be had.
* Documentation - want to gain feedback on implementation prior to making
changes.
* Update regression tests, rules test for system_views - want to gain
feedback on approach to handling pg_roles, etc. before updating.

Also, what would be the community preference on tracking these
attached/proposed changes? Should I create a separate entry in the next CF
for this item (seems prudent) or would it be preferred to keep it attached
to the current 'new attributes' CF entry?

Thanks,
Adam

--
Adam Brightwell - adam(dot)brightwell(at)crunchydatasolutions(dot)com
Database Engineer - www.crunchydatasolutions.com