"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
