Stephen Frost <sfr...@snowman.net> writes: > * Tom Lane (t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers