Re: Proposal: Solving the "Return proper effected tuple count

Hello Bruce,

Monday, September 9, 2002, 12:16:32 AM, you wrote:

BM> Joe Conway wrote:

BM> Any suggestion on how to show the tag mutated? Do we want to add more
BM> tag possibilities?
Again, I don't agree with PQcmdStatus() returning a pseudo-keyword,
since I would expect a SQL command executed.
I prefer Tom's suggestion of returning the same kind of command
executed, or the last command as of Proposal #1.

>> > I don't think we should add tuple counts from different commands, i.e.
>> > adding UPDATE and DELETE counts just yeilds a totally meaningless
>> > number.
>>
>> I don't know about that. The number of "rows affected" is indeed this
>> number. It's just that they were not all affected in the same way.

BM> Yes, that is true. The problem is that a DELETE returning a value of 10
BM> may have deleted only one row and updated another 9 rows. In such
BM> cases, returning 1 is better. Of course, if there are multiple deletes
BM> then perhaps the total is better, but then again, there is no way to
BM> flag this so we have to do one or the other consistently.
BM>
BM> The real problem which you outline is that suppose the delete does _no_
BM> deletes but only inserts. In my plan, we would return zero while in
BM> yours you would return the rows updated.
You have a good point here, Bruce. And for avoiding it, maybe Tom's
suggestion is the best. Unless the new API as of Proposal #3 is
introduced.

BM> In my view, if you return a delete tag, you better only count deletes.
Yes, this is Tom's Proposal and it makes more sense when you imagine a
case situation.
Proposal #1 tried to be more compatible with the behavior of multiple
commands execution but that would lead us to bad situations like
Bruce exposes here.

BM> Also, your total affected isn't going to work well with INSERT because
BM> we could return a non-1 for rows affected and still return an OID, which
BM> would be quite confusing. I did the total only matching tags because it
BM> does mesh with the INSERT behavior.
Even if this is 100% true, I'm afraid the only way to cover all
specific situations is the new API. Let's remember it's easy to
implement, and could server to both multiple commands execution *and*
this rules situation.

>> > I don't think there is any need/desire to add additional API routines to
>> > handle multiple return values.
>>
>> Agreed.

BM> Yep.
OK, this counts two points against the new API :)

-------------
Best regards,
Steve Howe mailto:howe(at)carcass(dot)dhs(dot)org