Role Attribute Bitmask Catalog Representation - Mailing list pgsql-hackers

From Adam Brightwell
Subject Role Attribute Bitmask Catalog Representation
Date
Msg-id CAKRt6CRskqEEMRw9pvFVyRcCvS9S_tZhVjBGFMnvYSo-pB5gRw@mail.gmail.com
Whole thread Raw
Responses Re: Role Attribute Bitmask Catalog Representation  (Andres Freund <andres@anarazel.de>)
Re: Role Attribute Bitmask Catalog Representation  (David G Johnston <david.g.johnston@gmail.com>)
Re: Role Attribute Bitmask Catalog Representation  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
All,

I am simply breaking this out into its own thread from the discussion on additional role attributes (http://www.postgresql.org/message-id/20141015052259.GG28859@tamriel.snowman.net).

A few related threads/discussions/posts:

* http://www.postgresql.org/message-id/20141016115914.GQ28859@tamriel.snowman.net
* http://www.postgresql.org/message-id/CA+TgmobkYXNOWKEKzX2qGPSr_nvacFGueV=orxND-xmZvOVYvg@mail.gmail.com
* http://www.postgresql.org/message-id/20141016115914.GQ28859@tamriel.snowman.net

Based on these above I have attached an initial WIP 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 - previous discussion indicated a potential desire for this, but I feel more discussion needs to occur around these before proposing as part of a patch.  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?  I also felt these were mutually exclusive from an implementation perspective and therefore thought it would be best to keep them separate.
* 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.

Thanks,
Adam

--
Adam Brightwell - adam.brightwell@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
Attachment

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Disabling auto.conf WAS: Turning recovery.conf into GUCs
Next
From: Stephen Frost
Date:
Subject: Re: postgresql.auto.conf comments