Karl,
* Karl Czajkowski (kar...@isi.edu) wrote:
> Ideally, I'd be able to write a policy that has conditions for each
> category of operation:
>
>POLICY FOR SELECT WITH expr1
>POLICY FOR INSERT WITH expr2
>POLICY FOR DELETE WITH expr3
>POLICY FOR UPDATE WITH expr4
It's possible
Karl,
* Karl Czajkowski (kar...@isi.edu) wrote:
> On Dec 18, Stephen Frost modulated:
> > Any UPDATE which requires SELECT rights on the table will require expr1
> > to pass AND expr4 (the UPDATE's USING clause) to pass. This is modeled
> > directly off of our existing GRANT/ACL system. The
On Dec 18, Stephen Frost modulated:
> I agree that it would be a nice addition, as I've said before.
OK, sorry I misunderstood earlier and thought you were dismissing the
idea as redundant with triggers. Thanks for your patience!
> ... We certainly won't be adding it into 9.5 and it's getting
On Dec 18, Stephen Frost modulated:
> Any UPDATE which requires SELECT rights on the table will require expr1
> to pass AND expr4 (the UPDATE's USING clause) to pass. This is modeled
> directly off of our existing GRANT/ACL system. The same is true for the
> other commands. Note that we
I feel that the fundamental question here is about the semantics of
"row" in row security. The core question is whether UPDATE has a
different semantics with respect to row identity and security context
than a sequence of DELETE, INSERT.
At the moment, the documented solution feels like "tuple
Karl,
* Karl Czajkowski (kar...@isi.edu) wrote:
> I've been trying to learn more about the row-security policies but
> coming up short in my searches. Was there any consideration to
> allowing access to both old and new row tuples in a POLICY ... CHECK
> expression? This idiom I've seen in the
* Karl Czajkowski (kar...@isi.edu) wrote:
> I think that there is significant overlap between authorization, state
> transition models, and data integrity constraints once you start
> considering collaborative applications with mutable records.
Even with OLD/NEW being available to UPDATE, many of
On Dec 16, Stephen Frost modulated:
> There is still a need to refer back to some kind of state that is
> external to the table under consideration to determine what the session
> level access is, no? Even if the ACLs are in a table somewhere, how do
> you know who the current user is?
>
Yes,
