Re: Proposal: Solving the "Return proper effected tuple - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Proposal: Solving the "Return proper effected tuple
Date
Msg-id 200209090321.g893LB520957@candle.pha.pa.us
Whole thread Raw
In response to Re: Proposal: Solving the "Return proper effected tuple count from complex commands [return]" issue  (Steve Howe <howe@carcass.dhs.org>)
Responses Re: Proposal: Solving the "Return proper effected tuple count from complex commands [return]" issue  (Steve Howe <howe@carcass.dhs.org>)
List pgsql-hackers
Steve Howe wrote:
> 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...

I don't like treating the last command as special when there is more
than one command.  Of course, if there is only no INSTEAD, the main
statement is the only one we care about returning information for.

> 
> 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.

Yes, that is a good point, i.e. rows effected.  However, see my previous
email on how this doesn't play with with INSERT.

> 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.


We don't like to add complexity if we can help it.


--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Steve Howe
Date:
Subject: Re: Proposal: Solving the "Return proper effected tuple count
Next
From: Bruce Momjian
Date:
Subject: Re: Proposal: Solving the "Return proper effected tuple