Nikolay, I think I must be missing your point. Even if updatable views existed, I would still have created Veil. The real point of Veil is to control each type of operation (insert, update, etc) on each record. With updatable views, you could avoid a lot of the tedium of creating the instead-of triggers for update, insert, etc. but you would have reduced the granularity of your access controls. If a user has select access to a record, they would also have insert, update and delete (as long as they have those privileges on the view). That is, if you can update *any* record in the view, you can update all of those records that you can see. You cannot have update privilege on some records, and select-only on others. This may suit your requirements but it may not suit everyones. In any case, the main goal of Veil is to support efficient, context-specific, querying of privileges. I don't see how any updatable view implementation will do this. I have tried to do exactly this with Oracle's updatable views and have never achieved usable levels of performance. Only by providing in-memory bitmaps of user privileges have I been able to achieve the level of performance that I require. The only alternative implementation that I considered was something like Oracle's Virtual Private Database, in which extra user-generated predicates are dynamically added to the where clauses of queries on protected tables. This would have been much harder to create, and would not work on existing installations with older version of Postgres. Having looked quite closely at Oracle's VPD, I am also not convinced that it offers either greater flexibility or the likelihood of better performance. I very much appreciate you taking the time to provide this feedback, and would like to hear your response to the above. Thanks. __ Marc On Mon, 2005-10-17 at 20:38 +0400, Nikolay Samokhvalov wrote: > IMHO, Veil is very strange project. Instead of concentrating on good > support of updatable views, developers are trying to reinvent the > wheel. Actually, if restriction-and-projection views would be > updatable w/o overhead (such as creating rules), there'll no need in > such project. It's one of the major roles of views - provide mechanism > to secure the data. > > Am I right? >
Attachment:
signature.asc
Description: This is a digitally signed message part
