* Karl Czajkowski (karlcz@xxxxxxx) 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 the state transistion checks which you describe may well be better suited to triggers rather than policies.. I can imagine such complicated transistions quickly moving beyond SQL expressions and into procedural logic. I don't believe using policies for UPDATE which simply end up calling a function to do a bunch of complicated considerations to be particularly better than an UPDATE trigger which does the same. > The next big leap beyond considering NEW and OLD values during > condition checks would be to use scalar subqueries to examine the row > within the context of other existing rows in the same or different > tables. I have not looked to see if this is possible in the current > policy system, but I imagine we would try hard to avoid doing this due > to performance implications, even if it is allowed... Policies are certainly able to have references to other tables through subqueries. You are correct that there are performance considerations, but those are essentially the same considerations you would have if the application was to perform the same joins and queries as part of the query, or if you were to include those in a view. Thanks! Stephen
Attachment:
signature.asc
Description: Digital signature
