> >It sounds like table || column is the check, so table implies > >all of columns. ie, revoking a column permission does nothing > >unless TABLE permission is also revoked. > > IF this will be implemented as suggested here, it will become extremely > counter-intuitive. Its just like you have access to a file if you have > (explicitly been granted) access to the file OR to its constaining > directory (thus sort of implicit). > > 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: [table permissions] + [positive column permissions] - [negative column permissions] However, this is both more complicated and possibly imposes a considerably larger performance penalty than the proposed design. In the proposed design, if the appropriate table permissions are granted (presumably the common case), we don't even need to look at the column permissions. But with this design, we need to check every column for negative permissions (unless we cache something at the table level that tells us whether any per-column permissions exist). You'll also need a more complicated grant/revoke syntax so that you can add a positive permission, add a negative permission, or eliminate the per-column setting entirely (whereas in the proposed design grant and revoke are logically opposites of each other, that's not the case here). ...Robert ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org