Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I already have a TODO item:
> > * Return proper effected tuple count from complex commands [return]
> > I am unsure if it will be fixed in 7.3 or not. It is still on the open
> > items list, and I think we have a general plan to fix it.
>
> I got distracted and wasn't following the thread a few days ago about
> the topic. Did people come to a consensus about how it should work?
OK, I am back. I think the most promising proposal was from you, Tom:
http://candle.pha.pa.us/mhonarc/todo.detail/return/msg00012.html
It basically breaks down the three results (tag, oid, tuple count), and
the INSTEAD/non-INSTEAD behavior.
I actually got a big chuckle from this paragraph:
Come on, guys, work with me a little here. I've thrown out severalalternative suggestions already, and all I've gotten
fromeither ofyou is refusal to think about the problem.
I liked the "work with me" phrase.
To summarize, with non-INSTEAD, we get the tag, oid, and tuple count of
the original query. Everyone agrees on that.
For non-INSTEAD, we have:
1) return original tag2) return oid if all inserts in the rule insert only one row3) return tuple count of all commands
withthe same tag
For item 2, it is possible to have multiple INSERTS in the rule and
return an oid if the sum of the inserts is only one row.
Item 3 is the most controversial. Some say sum all tuple counts, i.e.
sum INSERT/UPDATE/DELETE. That just seems to messy to me. I think
summing only the matching tags has the highest probability of returning
a meaningful number.
Also, item 2 and 3 work well together with INSERT because a tuple count
of 1 returns an oid, while > 1 does not, which is consistent with a
non-rule insert.
(FYI, I am still working SSL.)
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073