> I don't think we should add tuple counts from different commands, i.e.
> adding UPDATE and DELETE counts just yields a totally meaningless
> number.
Agreed.
> I don't think there is any need/desire to add additional API routines to
> handle multiple return values.
Yup.
> Can I get some votes on this?
I vote for Tom's proposal, especially regarding non instead rules (a note to Steve:
non instead rules are not for views).
I also think summing up is good, it would nicely fit the partitioned table requirements.
And even if you imagine an insert statement with one row, even though I would be quite
surprised if I got 3 rows inserted as an answer, I think it is the dba's responsibility
to do the 2nd and 3rd row with a non instead rule or a trigger.
For the same reason I would not restrict the count to one tag (do what you don't want in
the count with a non instead rule or a trigger).
I would vote for OID from first or last command. And I would disregarding the tag, since that
gives me the power to transparently move an updated table to a history keeping table,
that only does inserts.
Whether first or last result is probably not so important, since the rule creator can
influence what is done first/last, no ? You'd only need to know which.
Andreas
