"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

Fri, 17 May 2002 09:31:08 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Queries using rules show no rows modified? 

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, Pennsylvania 19026

Sat, 15 Jun 2002 01:32:01 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Queries using rules show no rows modified?
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Has this been resolved and patched?

No, I think we were still debating how it should work when the
discussion died off...

			regards, tom lane

Sat, 15 Jun 2002 12:08:20 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Queries using rules show no rows modified? 