Re: Proposal: Solving the "Return proper effected tuple count from complex commands [return]" issue

Hello Bruce,

Sunday, September 8, 2002, 10:52:45 PM, you wrote:

BM> I liked option #2. I don't think the _last_ query in a rule should have
BM> any special handling.

BM> So, to summarize #2, we have:

BM> if no INSTEAD,
BM> return value of original command
The problem is, this would lead us to the same behavior of Proposal
#1 (returning the value for the last command executed), which you
didn't like...

BM> if INSTEAD,
BM> return tag of original command
BM> return sum of all affected rows with the same tag
BM> return OID if all INSERTs in the rule insert only one row, else zero

BM> This INSERT behavior seems consistent with INSERTs inserting multiple
BM> rows via INSERT INTO ... SELECT:

BM> test=> create table x (y int);
BM> inseCREATE TABLE
BM> test=> insert into x select 1;
BM> INSERT 507324 1
BM> ^^^^^^
BM> test=> insert into x select 1 union select 2;
BM> INSERT 0 2
BM> ^

BM> I don't think we should add tuple counts from different commands, i.e.
BM> adding UPDATE and DELETE counts just yeilds a totally meaningless
BM> number.
But this *is* the total number of rows affected. There is no current
(defined) behavior of "rows affected by the same kind of command
issued", although I agree it makes some sense.

BM> I don't think there is any need/desire to add additional API routines to
BM> handle multiple return values.
I'm ok with that if we can reach an agreement on how the existing API
should work. But as I stated, a new API would be a no-discussion way
to solve this, and preferably extending some of the other proposals.

BM> Can I get some votes on this? We have one user very determined to get a
BM> fix, and the TODO.detail file has another user who really wants a fix.
*Please* let's do it :)

Thanks.

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