Re: [COMMITTERS] pgsql: Use a bitmask to represent role attributes

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> I have to apologize for not having paid more attention, but ... is this
>> *really* such a great idea? You've just broken any client-side code
>> that looks directly at pg_authid.

> Anything which looks at pg_authid for the relevant columns needs to be
> updated for the changes which were made for rolreplication previously,
> and now rolbypassrls and any other role attributes added.

Right. 95% of the compatibility costs of adding a property are going to
be sunk in any case because clients will need to know what flags exist,
how to spell them in CREATE/ALTER USER commands, etc. (Some of this could
be alleviated perhaps if we invented a server-side function that produced
a text string representing all of a user's properties, but that's quite
orthogonal to this patch.)

> That's correct, however, this change wasn't intended to insulate anyone
> from those compatibility changes but rather to make better use of the
> bytes in each pg_authid record. We were already up to 8 individual bool
> columns, wasting space for each.

You're really seriously concerned about a couple of dozen bytes per role?
That is micro-optimization of the very worst sort. We are routinely
wasting multiples of that on things like using "name" rather than a
variable-length text representation for name columns, and I don't think
anyone is especially concerned about that anymore. Maybe back in the
nineties it'd have been worth bit-shaving that way.

To me, a bitmask might make sense if the properties could usefully be
manipulated as a unit, but I'm not seeing any such advantage here.

> For my 2c, I do think this is the right direction to go in as adding
> another 15 boolean columns to pg_authid definitely strikes me as a bad
> idea, but we can certainly discuss the trade-offs.

Meh. To the extent that users look at pg_roles rather than pg_authid,
it's going to look like another 15 boolean columns to them anyway ...
except that now, those columns are suddenly a lot more expensive to read.

15-20 more bool columns sounds entirely fine to me. If we were talking
a couple of hundred, I'd start to worry; but this approach would not
handle that very well either.

regards, tom lane