Re: [PATCHES] Merge pg_shadow && pg_group -- UNTESTED

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > Here's a proof-of-concept pretty much untested (it compiles) patch
> > against HEAD for review of the general approach I'm taking to
> > merging pg_shadow and pg_group. This is in order to support group
> > ownership and eventually roles. This patch includes my grammar and
> > get_grosysid move patches, and so conflicts with them.
>
> One point is that you can't simply whack pg_shadow around and eliminate
> pg_group, because that will break lord-knows-how-much client software
> that looks at these tables. What I'm envisioning is to create a new
> system catalog (say pg_role) that holds the New Truth, and then make
> pg_shadow and pg_group be predefined views on this catalog that provide
> as much backwards compatibility as we can manage.

Ok. Can I get some help defining what the New Truth will look like
then? I understand users and groups pretty well but I'm not 100% sure
about roles. Is it as simple as what my changed pg_shadow looks like?
What's the difference between a role, a user and a group? Can a role
log in/have a password? Can a role own an object? If a role owns an
object, can any users who have that role {drop, create index, etc} it?

Once we get the layout of pg_role defined I think I'll be able to make
much better progress towards what you're looking for. :)

> A related point is that I hope soon to get rid of type AclId and
> usesysid/grosysid/rolesysid and start identifying roles by Oids.

Alright. That doesn't sound too bad.

> This is connected to Alvaro's work to create proper dependencies
> for object owners and privilege entries: once that exists and you
> can't drop a referenced role, there will be no need to allow explicit
> setting of the SYSID for a new user. Not sure if you want to do any
> of the associated changes in your patch, but if int4 is bugging you
> then feel free to change it.

Ok, I probably will. Should I be concerned with trying to make
'smallish' patches that build upon each other (ie: change to pg_role
first, then change AclId to Oid, or whatever) or will one larger patch
that takes care of it all be ok?

Thanks,

Stephen