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:[EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]