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

From Joe Conway
Subject Re: Proposal: Solving the "Return proper effected tuple
Date
Msg-id 3D7C0D75.90805@joeconway.com
Whole thread Raw
In response to Re: Proposal: Solving the "Return proper effected tuple count  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Proposal: Solving the "Return proper effected tuple count  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Proposal: Solving the "Return proper effected tuple count  (Steve Howe <howe@carcass.dhs.org>)
List pgsql-hackers
Bruce Momjian wrote:
> I liked option #2.  I don't think the _last_ query in a rule should have
> any special handling.
> 
> So, to summarize #2, we have:
> 
>     if no INSTEAD, 
>     return value of original command
> 
>     if INSTEAD, 
>     return tag of original command
>     return sum of all affected rows with the same tag
>     return OID if all INSERTs in the rule insert only one row, else zero
> 

How about:
    if no INSTEAD,    return value of original command
    if INSTEAD,    return tag MUTATED    return sum of sum of tuple counts of all replacement commands    return OID if
sumof all replacement INSERTs in the rule inserted      only one row, else zero
 

This is basically Tom's proposal, but substituting MUTATED for the 
original command tag name acknowledges that the original command was not  executed unchanged. It also serves as a
warningthat the affected 
 
tuple count is from one or more substitute operations, not the original 
command.

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

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

Agreed.

> 
> Can I get some votes on this?  We have one user very determined to get a
> fix, and the TODO.detail file has another user who really wants a fix.

+1 for the version above ;-)

Joe



pgsql-hackers by date:

Previous
From: "Christopher Kings-Lynne"
Date:
Subject: Australian Open Source Awards
Next
From: "Marc G. Fournier"
Date:
Subject: Re: [GENERAL] Australian Open Source Awards