* 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
