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 <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
