Joshua Brindle <met...@manicmethod.com> writes: > partitions don't help because, once again, the application would be making the > determination about which partition to query.
Not necessarily since the database can be programmed to automatically put the records into the right partition. Right now it's a pain but we're definitely headed in that direction. > Further, partitioning isn't fine grained. I can't say user X can read secret > rows and read/write top secret rows and get that data out in a transparent way > (the applications would have to be aware of the partitions). Relabeling of > data > also looks like a challenge with partitions (if I correctly understand how > they > work). I think the "transparent" is the source of the problem. The application should issue a query for the data it wants. It shouldn't "transparently" get magic extra clauses attached to the query. That's where the SQL semantics are being violated. Row-level security isn't inherently a problem. It's just that the security is affecting the data returned that's causing a problem. I don't think partitioning is really the same thing as row-level security. But I wonder if some of the same infrastructure could be used for both -- once we have it. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
