> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
