Re: Role Attribute Bitmask Catalog Representation - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Role Attribute Bitmask Catalog Representation
Date
Msg-id 20141126123738.GU28859@tamriel.snowman.net
Whole thread Raw
In response to Role Attribute Bitmask Catalog Representation  (Adam Brightwell <adam.brightwell@crunchydatasolutions.com>)
Responses Re: Role Attribute Bitmask Catalog Representation  (Adam Brightwell <adam.brightwell@crunchydatasolutions.com>)
List pgsql-hackers
Adam,

* Adam Brightwell (adam.brightwell@crunchydatasolutions.com) wrote:
> 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
> ).

Makes sense to me, thanks.

> Based on these above I have attached an initial WIP patch for review and
> discussion that takes a swing at changing the catalog representation.

Just a quick initial look, but I don't think we want to #include
parsenodes.h into pg_authid.h.  Why not put the #define ROLE_ATTR_* into
pg_authid.h instead?  We have similar #define's in other catalog .h's
(PROARGMODE_*, RELKIND_*, etc).

I'm also not a huge fan of the hard-coded 255 for the default superuser.
That goes back to the other question of if we should bother having those
explicitly listed at all, but I'd suggest having a #define for 'all'
bits to be true (for currently used bits) and then a comment above the
superuser which references that #define (we can't use the #define
directly or we'd be including pg_authid.h into pg_proc.h, which isn't a
good idea either; if we really want to use the #define, genbki.pl could
be adjusted to find the #define similar to what it does for PGUID and
PGNSP).
Thanks!
    Stephen

pgsql-hackers by date:

Previous
From: Albe Laurenz
Date:
Subject: Re: Using RTLD_DEEPBIND to handle symbol conflicts in loaded libraries
Next
From: Alex Shulgin
Date:
Subject: Follow up to irc on CREATE INDEX vs. maintenance_work_mem on 9.3