Thread: Re: Proposal: Solving the "Return proper effected tuple count
Re: Proposal: Solving the "Return proper effected tuple count
From
"Zeugswetter Andreas SB SD"
Date:
> 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