Bruce Momjian wrote:
>
> Jan Wieck wrote:
> > We should surely keep this on a much more technical level and avoid any
> > personal offendings. To do so, please explain to me why you think that
> > triggers and constraints are out of focus here? What is the difference
> > between a trigger, a rule and an instead rule from a business process
> > oriented point of view? I think there is none at all. They are just
> > different techniques to do one and the same, implement business logic in
> > the database system.
>
> All the problems here are coming from INSTEAD rules. We don't have
> INSTEAD triggers or contraints.
So a BEFORE INSERT trigger on table1 that does an UPDATE to table2 and
then returns NULL is not effectively the same as an ON INSERT ... DO
INSTEAD UPDATE ... rule? Hmmm, the end result is exactly the same so
what do you call it?
I think we will have no chance to really return the number of
VIEW-tuples affected. So any implementation is only a guess and we could
simply return fixed 42 if "some" tuples where affected at all. This
return is as wrong (according to Steve) as everything else but at least
we have a clear definition what it means.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
