Robert Haas wrote:
>> My strongly opinion is that, REVOKE column-level priviledge should
>> revoke access to that column, in effect it should reduce the table-level
>> grant to column-level grants.
>>
>
> I think this causes problems when columns are added to the table. If
> table X has columns A, B, C, and D, and the user has access to A-C but
> not D, then what happens when column E is added? Logically, if the user
> started with table access and column D was revoked, then they should
> have access to column E. But if they started with access to nothing and
> were explicitly granted A-C, then they shouldn't.
>
> You could solve this by having explicit positive and negative ACLs, i.e.
> your permissions for a particular column are:
>
Agreed I think.
While the explicit Table + Positive - Negative is perhaps ideal and the
most intuitive (and I think it is) for now I suppose my point was simply
that this should be clearly documented.
On the question of SELECT raising an error vs omitting the rows, it
clearly needs to raise an error in some cases (INSERTS, and FK
situations, where there is no permission for the FK). I suppose it'll
need to raise an error on the Select * case as well. For systems behind
glue to the database, raising errors in these situations will cause some
pain as usually the systems do a lot of inspection of the database. I
don't think pg_attribute is MVCC safe? As more stuff is added to
pg_attribute eventually that risks causing some problems doesn't it?
- August
