Re: [COMMITTERS] pgsql: Use a bitmask to represent role attributes
От | Stephen Frost |
---|---|
Тема | Re: [COMMITTERS] pgsql: Use a bitmask to represent role attributes |
Дата | |
Msg-id | 20141223160900.GF3062@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Use a bitmask to represent role attributes (Andres Freund <andres@2ndquadrant.com>) |
Список | pgsql-hackers |
* Andres Freund (andres@2ndquadrant.com) wrote: > On 2014-12-23 10:40:15 -0500, Robert Haas wrote: > > I would have preferred (and I believe argued for) keeping the existing > > catalog representation for existing attributes and using a bitmask for > > new ones, to avoid breaking client code. But I am not sure if that's > > actually the best decision. > > I personally think in this case the clear break is slightly better than > having different styles of representation around for a long while. Yes, I'm completely with Andres on this point. Having a mixed case where there are some boolean columns and then a bitmask strikes as the worst approach- it doesn't save anyone from the client-side code changes but rather makes them have to consider both ways and keep an internal list somewhere of which ones are in boolean columns and which are in the bitmask, yuck. > > I find Tom's concern about needing more > > than 64 attributes to be ill-founded; I can't really see that > > happening on any timescale that matters. > > I personally would prefer a 'custom' type to represent the > permissions. Internally that could very well be current bitmask, but the > external representation could be more complex (i.e. some textual > representation). That'd make it easy to make the representation wider/more > complex if needed. In some ways, I feel like this is what we actually have now.. If you consider pg_authid to be 'internal' and pg_roles to be 'external'. That said, I'm not against what you're proposing, but at the same time I'm not quite sure what that would end up looking like or how difficult it would be to support a complex type in the catalog and I don't think there's any way it would address the on-disk size concern, and if we have to start having a different C-level representation for pg_authid than the on-disk representation, well, that strikes me as a lot more complicated too.. Thanks, Stephen
В списке pgsql-hackers по дате отправления: