Am Donnerstag, 31. August 2006 15:55 schrieb Tom Lane:
> >> I'm unclear as to why you've got DO INSTEAD NOTHING rules in there ---
> >
> > You need to have one unconditional rule if you have a bunch of
> > conditional ones. The system does not see through the fact that the
> > conditional ones cover all cases.
>
> AFAICS, for the cases we are able to implement within the existing rule
> mechanism, there should be exactly one unconditional rule. If you
> propose more, then you are going to have insurmountable problems with
> the usual sorts of multiple-evaluation risks.
I'm not sure what you are saying here ...
The implementation creates, for each of the three actions INSERT, UPDATE,
DELETE, one conditional rule that redirects the action from the view into the
unterlying table, conditional on the view condition being fulfilled. The
unconditional DO INSTEAD NOTHING rule then catches the cases where the view
condition is not fulfilled. So there is, for each action, exactly one
conditional and one unconditional rule. Which is consistent with what you
said above, so I don't see the problem.
> The proposed WITH CHECK OPTION implementation is unworkable for exactly
> this reason --- it will give the wrong answers in the presence of
> volatile functions such as nextval().
I'm not sure why anyone would want to define a view condition containing a
volatile function. At least it wouldn't put a major dent into this feature
if such views were decreed not updatable.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/