Re: Queries using rules show no rows modified?
От | Tom Lane |
---|---|
Тема | Re: Queries using rules show no rows modified? |
Дата | |
Msg-id | 3876.1021642268@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Queries using rules show no rows modified? (Michael Alan Dorman <mdorman@debian.org>) |
Ответы |
Re: Queries using rules show no rows modified?
|
Список | pgsql-hackers |
"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
В списке pgsql-hackers по дате отправления: