Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> 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:

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 several
        alternative suggestions already, and all I've gotten from either of
        you 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 tag
        2) return oid if all inserts in the rule insert only one row
        3) return tuple count of all commands with the 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                        |
  [EMAIL PROTECTED]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Reply via email to