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:[EMAIL PROTECTED]
---------------------------(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
