Tom Lane <t...@sss.pgh.pa.us> writes: > I don't believe I will ever think that row-level checks are a good idea; as > long as those are in the patch I will vote against applying it.
I think we're conflating two behaviours here. The data hiding behaviour clearly changes the semantics of queries in ways that make a lot of deductions about the data incorrect. That's a pretty severe problem which would cause massive consequences down the road. The imposing of security restrictions based on the data in the row isn't really in the same league. I'm not sure I see any semantic problems with it at all. It's still true that it would be quite invasive to Postgres to implement. The current security restrictions are all checked and determined statically based on the query. Once a query is planned we can execute it without checking any security constraints at run-time. I don't think raising partitioning makes a useful contribution to this discussion. Firstly, it's not like partitioning doesn't change SQL semantics in its own way anyways. Even aside from that, partitioning is largely about the location that data is stored. Forcing data to be stored in different physical places just because our security model is based on the place the data is stored is kind of silly. Unless perhaps we implement partitioning which supports having many partitions share the same underlying, er, physical partition. But then I don't see how that's any different from row-level permissions. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
