
> 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

Mon, 9 Sep 2002 17:04:39 +0200
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
Re: Proposal: Solving the "Return proper effected tuple count