Has this been resolved and patched?
--------------------------------------------------------------------------- Tom Lane wrote: > "Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes: > > Tom Lane <[EMAIL PROTECTED]> writes: > >> Michael seems to feel that the tuple count should be nonzero if any > >> of the replacement operations did anything at all. > > > Here we usually add triggers, for replication, accounting, setting of > > calculated rows ... In all of our cases we want the addition of a trigger > > (or rule on a table) to be transparent to the client. > > Yeah. Triggers wouldn't affect this anyway, unless they tell the system > to suppress insertion/update/deletion of some tuples, in which case I > think it is correct not to count those tuples (certainly that's how the > code has always acted). As far as rules go, the last proposal that I > made would return the tuple count of the original query as long as there > were no INSTEAD rules --- if you have only actions *added* by rules then > they are transparent. > > The hard case is where the original query is not executed because of an > INSTEAD rule. As the code presently stands, you get "UPDATE 0" (or > INSERT or DELETE 0) in that case, regardless of what else was done > instead by the rule. I thought that was OK when we put the change in, > but it seems clear that people do not like that behavior. The notion > of "keep it transparent" doesn't seem to help here. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
