Andres, Thanks for the feedback.
> * int64 (C) to int8 (SQL) mapping for genbki. > > That definitely should be a separate patch. Which can be committed much > earlier than the rest - even if we don't actually end up needing it for > this feature, it's still good to have it. Agreed. I had previously submitted this as a separate patch, but I think it got lost in the weeds. At any rate, here is the relevant post: http://www.postgresql.org/message-id/CAKRt6CTgJdeGFqXevrp-DizaeHmg8gNVqu8n5T=ix3javpw...@mail.gmail.com > > * replace all role attributes columns in pg_authid with single int64 > column > > named rolattr. > > * update CreateRole and AlterRole to use rolattr. > > * update all has_*_privilege functions to check rolattr. > > * builtin SQL function 'has_role_attribute' that takes a role oid and > text > > name of the attribute as input and returns a boolean. > > I think if we're going to do this - and I'm not yet convinced that > that's the best route, we should add returns all permissions a user > has. Right now that's quite easily queryable, but it won't be after > moving everything into one column. You'd need to manually use all has_*_ > functions... Yes, you've added them already to pg_roles, but there's > sometimes good reasons to go to pg_authid instead. > This is a good point. I'll start looking at this and see what I can come up with. An array representation was also suggested by Simon ( http://www.postgresql.org/message-id/ca+u5nmjgvdz6jx_ybjk99nj7mwfgfvemxtdc44lvhq64gkn...@mail.gmail.com). Obviously there are pro's and con's to either approach. I'm not married to it, but felt that a bitmask was certainly more efficient. However, I know that an array would be more extensible given that we could envision more than 64 role attributes. I'm uncertain if that is a potential reality or not, but I believe it is certainly worth considering. -Adam -- Adam Brightwell - adam.brightw...@crunchydatasolutions.com Database Engineer - www.crunchydatasolutions.com
