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 accomedate group
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' owners and
negative numbers are 'group' owners, where the group id is the
abs(relowner). Similar to (a) but seems kind of nasty to me. Also
means that '0' couldn't ever be used for a system id, and that it'd
be more difficult to change 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