Peter Eisentraut wrote:
> On Thursday 11 December 2008 17:04:05 Bruce Momjian wrote:
> > The idea is that the security columns will hold an OID and the OID will
> > point to a row in a table that contains the security rights/ACL for the
> > column, with multiple rows using the same rights OID.
>
> That sounds somewhat scary for a number of reasons:
>
> 1. Running out of OIDs, the main reason why we got rid of OIDs in user tables
> by default. This would essentially put them back.
>
> 2. You are implying some kind of ACL unification algorithm, to combine
> identical ACLs under one ID. How will that work, and how will it be managed?
>
> 3. The performance impact of having to look somewhere else for every row
> fetched. If you propose a cache, note that this cache has potentially one
> possible entry for every row in the database. That would need significant
> thought and tuning.
>
> 4. Size scalability of the whole thing. When using IDs as references is being
> proposed, somewhere in there is a total size limitation for a row-security
> enabled database.
>
> Even if you manage to solve #2, is this cleanup feasible to run on a database
> that has run into the limits of #4?
>
> I suppose that SELinux in the kernel addresses these issues somehow (e.g.
> caching), but what would the SQL-only solution do?
Agreed.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +