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?