Jan Wieck wrote:
> Tom Lane wrote:
>
> > This might be better done with a trigger than a rule. For one thing,
> > a trigger can easily raise an exception. MHO is that rules are good
> > when you need to update multiple rows in other tables when certain
> > things happen. If you just want to validate or twiddle an individual
> > tuple as it's inserted/updated, a trigger is a good bet.
>
> But the trigger aproach requires access permissions to the
> base table in the first place, and exactly that's what Kyle
> want to restrict.
That's right.
> Kyle, I doubt if you need the condition in the update rule at
> all. As far as I understood, your view restricts what the
> user can see from the base table. This restricted SELECT rule
> is applied to UPDATE events as well, so the UPDATE can never
> affect rows which are invisible through the view.
This hadn't occurred to me but makes sense now that you say it. Taking that into
consideration will
make my job a bit simpler.
The only complication is
that there are a class of records which the user should be able to view, but not
modify. For example,
the employee can create and modify working records as long as the only
modification to their status
is to move them on to "open status" (creating an "approved" record would be a bad
idea.)
But the user should be able to view all their records (working, open, approved,
and even paid).
Hence, the restrictions on update are more stringent than those on select.
