Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> Alternatively, since you really only need two bits per privilege,
>> perhaps a pair of BIT (VARYING?) fields would be a more effective
>> approach. BIT VARYING would have the nice property that adding a new
>> privilege type doesn't force initdb.
>
Tom Lane writes:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > pg_privilege (
> > priobj oid, -- oid of table, column, function, etc.
> > prigrantor oid, -- user who granted the privilege
> > prigrantee oid, -- user who owns the privilege
>
> W
First, let me say that just because Oracle does it this way doesn't make
it better but...
Oracle divides privileges into 2 categories:
Object privileges
System privileges
The Object privileges are the ones you describe. And I agree
fundamentally with your design. Although I would have (a) used
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> pg_privilege (
> priobj oid, -- oid of table, column, function, etc.
> prigrantor oid, -- user who granted the privilege
> prigrantee oid, -- user who owns the privilege
What about groups? What a
Mike Mascari writes:
> That looks quite nice. I do have 3 quick questions though. First, I
> assume that the prigrantee could also be a group id?
Yes. It was also suggested making two different grantee columns for users
and groups, but I'm not yet convinced of that. It's an option though.
> S
So, this will remove the relacl field from pg_class, making pg_class
a fixed tuple-length table: that might actually speed access: there
are shortcircuits in place to speed pointer math when this is true.
The implementation looks fine to me, as well. How are group privileges
going to be handled w
Peter Eisentraut wrote:
> I have devised something more efficient:
>
> pg_privilege (
> priobj oid, -- oid of table, column, etc.
> prigrantor oid, -- user who granted the privilege
> prigrantee oid, -- user who owns the privilege
>
> pris
