Tom Lane <tgl@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!
