Re: Role Attribute Bitmask Catalog Representation - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Role Attribute Bitmask Catalog Representation
Date
Msg-id 20141126001823.GQ28859@tamriel.snowman.net
Whole thread Raw
In response to Re: Role Attribute Bitmask Catalog Representation  (Adam Brightwell <adam.brightwell@crunchydatasolutions.com>)
Responses Re: Role Attribute Bitmask Catalog Representation  (Adam Brightwell <adam.brightwell@crunchydatasolutions.com>)
List pgsql-hackers
Adam,

* Adam Brightwell (adam.brightwell@crunchydatasolutions.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

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Doing better at HINTing an appropriate column within errorMissingColumn()
Next
From: Adam Brightwell
Date:
Subject: Re: Role Attribute Bitmask Catalog Representation