Karl, * Karl Czajkowski (karlcz@xxxxxxx) 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 same is true for the > > other commands. Note that we explicitly want an independent USING > > clause for expr4 as you may wish to reduce the set of rows which may be > > UPDATE'd to be less than the set which are visible via SELECT. > > > > I anticipate adding the ability to have "restrictive" policies also, in > > the future. > > Right, I think I understand that. However, my argument was (and > remains) that I think the update conditions need to be able to access > OLD and NEW row values to decide whether the existing row security > context allows the new update content. This update decision is > inherently different from select, insert, and delete decisions. I agree that it would be a nice addition, as I've said before. We certainly won't be adding it into 9.5 and it's getting pretty late for 9.6 too, but I'm anxious to see just how RLS is used in the field (it's certainly satisfying the use-cases for which it was developed, but I anticipate a lot of new and interesting uses will come up). > I don't think that two separate decisions are sufficient: > > 1. OLD row can be updated (the USING condition?) > 2. NEW row is acceptable (the CHECK condition?) > > when considering the row lifecycle as having continuity of identity > and security context. I think that the second decision needs to have > the option to compare OLD and NEW to decide that the new row is an > acceptable transform of the existing row, preserving whatever identity > and/or security context is important in a particular system of > policies. Yeah, I tend to think it's more useful in the CHECK condition than the USING condition. That would, I expect, also be more practical as it means we wouldn't be changing anything about how the conditionals are added to the UPDATE query which is pulling the rows to operate on. Thanks! Stephen
Attachment:
signature.asc
Description: Digital signature
