Обсуждение: 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