Re: [COMMITTERS] pgsql: Use a bitmask to represent role attributes - Mailing list pgsql-hackers

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > Tom Lane wrote:
> >> Again, I suppose I should have objected earlier, but I really seriously
> >> doubt that this is a good idea.
>
> > Ugh.  I thought we had a consensus that this was the accepted way
> > forward; that's my reading of the old thread,
> >
http://www.postgresql.org/message-id/flat/20141016133218.GW28859@tamriel.snowman.net#20141016133218.GW28859@tamriel.snowman.net
>
> I was aware that we were thinking of introducing a bunch more role
> attributes, but I'm wondering what's the rationale for assuming that
> (a) they'll all be booleans,

I attempted to do a comprehensive review of the case by looking at all
of the existing superuser checks and considering where it made sense to
make things more flexible.  The result was specifically that they were
all boolean cases except for the previously-discussed 'create directory'
idea.  Had there been other cases which weren't boolean, I would have
been looking for another representation.

That said, this does not wall-off additional columns going into
pg_authid later, if there are any non-boolean cases which would make
sense.  Those cases, I suspect, would lead to new catalog tables in
their own right anyway though, rather than additional columns in
pg_authid.

The 'create directory' idea certainly made more sense to me with a new
catalog table.  Having an array of directories in pg_authid was never
considered, though I did consider adding a catalog table which was
essentially role+key/value where 'value' was an arbitrary string or
perhaps bytea blob, but all the boolean cases would have gone into
pg_authid and that new catalog would have only been used for the
'directory' case (or at least, I couldn't find any other use-cases for
it in my review).

> and (b) there will never, ever, be more
> than 64 of them.

I do not think this approach walls off adding more than 64.  On the
other hand, I don't like the idea of doubling the size of pg_authid if
we do get to 64 because we really want to use boolean columns instead of
a bitmap.

> The argument that lots of boolean columns won't
> scale nicely doesn't seem to lead to the conclusion that a fixed-size
> bitmap is better.

Perhaps it's because I just recently came out of an environment where we
were constantly fighting with size issues for boolean values, but
boolean columns definitely don't scale nicely.  I admit that we still
have larger issues when it comes to running databases with lots of roles
(which means people tend to not do it), such as being unable to
partition catalog tables, but I'm still hopefull we'll one day get to a
point where more users can exist as real database users (and therefore
have the database enforcing the permission system, rather than each
application having to write its own) and I'd rather not have pg_authid
bloated without cause.

> I'd have gone with just adding more bool columns as needed.

I don't think I was the only one concerned that adding a bunch of new
columns would bloat the size of pg_authid and the C structure behind it,
but I'm not remembering offhand who else considered it.
Thanks,
    Stephen