Re: Check old and new tuple in row-level policy?

* Karl Czajkowski (karlcz(at)isi(dot)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 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