Thread: pg_class changes for group ownership

Greetings,
 Due to the fact that group system id's and user system id's can overlap, pg_class will need to change in order to
accomedategroup ownership.  The things I've thought of so far, in order of preference:
 
 a) Add a boolean field 'relgroup_owned' which is 'false' when relowner    is a user and 'true' when relowner is a
group.
 b) Add an integer field 'relgroup_owner' which is the 'group' owner of    the relation, this would imply 'dual'
ownership,ala unix    semantics, but doesn't quite fit in w/ Postgres ACLs, imv.
 
 c) Don't change pg_class's structure but change the meaning of    'relowner' such that positive numbers are 'user'
ownersand    negative numbers are 'group' owners, where the group id is the    abs(relowner).  Similar to (a) but seems
kindof nasty to me.  Also    means that '0' couldn't ever be used for a system id, and that it'd    be more difficult
tochange relowner to Oid later (probably    involving something like (a)).
 
  Thoughts?
      Thanks,
    Stephen

Stephen Frost <sfrost@snowman.net> writes:
>   Due to the fact that group system id's and user system id's can
>   overlap, pg_class will need to change in order to accomedate group
>   ownership.  The things I've thought of so far, in order of preference:

I thought that the agreed-on direction for this was to merge users and
groups into a single kind of entity, or at least make sure that they
share a common unique identifier space.  Then AclId is still sufficient
as an ownership indicator, and you don't need any of these kluges.
IIRC something of this sort is needed for improved compliance with the
SQL spec anyway --- see past discussions about "roles".
        regards, tom lane

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> >   Due to the fact that group system id's and user system id's can
> >   overlap, pg_class will need to change in order to accomedate group
> >   ownership.  The things I've thought of so far, in order of preference:
>
> I thought that the agreed-on direction for this was to merge users and
> groups into a single kind of entity, or at least make sure that they
> share a common unique identifier space.  Then AclId is still sufficient
> as an ownership indicator, and you don't need any of these kluges.
> IIRC something of this sort is needed for improved compliance with the
> SQL spec anyway --- see past discussions about "roles".

Ah, alright, sounds good to me.  I'll look into making them share a
common unique identifier space, that shouldn't be too difficult.  Of
course, that'll require a dump/restore, I expect..  I don't suppose that
could possibly happen before 8.0, eh? :)
Stephen

Stephen Frost <sfrost@snowman.net> writes:
> Ah, alright, sounds good to me.  I'll look into making them share a
> common unique identifier space, that shouldn't be too difficult.  Of
> course, that'll require a dump/restore, I expect..  I don't suppose that
> could possibly happen before 8.0, eh? :)

Changing pg_class would have the same problem ...
        regards, tom lane

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > Ah, alright, sounds good to me.  I'll look into making them share a
> > common unique identifier space, that shouldn't be too difficult.  Of
> > course, that'll require a dump/restore, I expect..  I don't suppose that
> > could possibly happen before 8.0, eh? :)
>
> Changing pg_class would have the same problem ...

Well, yes, but that's no longer the issue.  I guess my thought was that
if we could get the common id space change in before 8.0 then group
ownership could possibly be introduced in 8.1 w/o having to do a
dump/restore.  I'm still relatively new to Postgres, is it normal to
require a dump/restore between semi-major (8.0 to 8.1) revisions?  If so
then it doesn't matter since I wouldn't expect group ownership to be
introduced prior to 8.1 (at the earliest..) anyway.
Thanks,
    Stephen

Stephen Frost <sfrost@snowman.net> writes:
> Well, yes, but that's no longer the issue.  I guess my thought was that
> if we could get the common id space change in before 8.0 then group
> ownership could possibly be introduced in 8.1 w/o having to do a
> dump/restore.

No chance whatever during RC stage.  We might have listened to such a
proposal in August, but it's not happening now.  Especially not when
you don't even have the patch yet ;-).  (FWIW, given the infrastructure
we have, I don't really see any way to enforce uniqueness except to
merge pg_shadow and pg_group into one table.  So it's not going to be
a trivial change.)

> I'm still relatively new to Postgres, is it normal to
> require a dump/restore between semi-major (8.0 to 8.1) revisions?

Yes.  There have been one or two such revisions that didn't require a
dump, but I doubt 8.1 will be one of them.
        regards, tom lane