Joshua Brindle <method@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'sPostgreSQL training!
