Has this been resolved and patched?
---------------------------------------------------------------------------
Tom Lane wrote:
> "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> > Tom Lane <tgl@sss.pgh.pa.us> 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 pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
