From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Adam Brightwell <adam(dot)brightwell(at)crunchydatasolutions(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Role Attribute Bitmask Catalog Representation |
Date: | 2014-11-26 00:18:23 |
Message-ID: | 20141126001823.GQ28859@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Adam,
* Adam Brightwell (adam(dot)brightwell(at)crunchydatasolutions(dot)com) wrote:
> Giving this some thought, I'm curious what would be acceptable as an end
> result, specifically related to how a query on pg_authid might look/work.
> I was able to preserve the structure of results from pg_roles, however,
> that same approach is obviously not possible with pg_authid. So, I'm
> curious what the thoughts might be on how to best solve this while
> minimizing impact (perhaps not possible) on users. Currently, my thought
> is to have a builtin function called 'get_all_role_attributes' or similar,
> that returns an array of each attribute in string form. My thoughts are
> that it might look something like the following:
Having an array sounds pretty reasonable to me.
> Another approach might be that the above function return a string of comma
> separated attributes, similar to what \du in psql does. IMO, I think the
> array approach would be more appropriate than a string but I'm willing to
> accept that neither is acceptable and would certainly be interested in
> opinions.
Users interested in having a string instead could use array_to_string().
Having to go the other way isn't as nice, imo.
Thanks!
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Adam Brightwell | 2014-11-26 00:55:46 | Re: Role Attribute Bitmask Catalog Representation |
Previous Message | Peter Geoghegan | 2014-11-26 00:13:36 | Re: Doing better at HINTing an appropriate column within errorMissingColumn() |