José Luis Tallón wrote: > On 12/23/2014 04:46 PM, Andres Freund wrote:
> >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. > > Indeed, though this would imply adding a new "bitstring?" type to core > Postgres. We already have varlena bitstrings, in the guise of types bit and varbit. > Do you have any further input on what this type would look like ? Any > operators that might be useful? ISTM that this would actually be the > greatest strength of a type proper (vs. "hardcoded" bit-wise operations in > core) I imagine something like the "reg*" types (regclass, regtype etc): on input you can pass them an OID, or an possibly-qualified object name; internally they store the OID. You can cast them to OID to obtain the numerical value, or just print them out to get the possibly-qualified name. In the case at hand, on output you would get the equivalent of the text[] you get from pg_role_all_attributes(), and you can input it in the same way or you can input the bitmask; and the underlying storage is the bitmask. This doesn't solve the client compatibility break, or the issue that querying pg_roles is expensive. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers