Re: Proposal: Solving the "Return proper effected tuple

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Steve Howe <howe(at)carcass(dot)dhs(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proposal: Solving the "Return proper effected tuple
Date: 2002-09-09 03:21:11
Message-ID: 200209090321.g893LB520957@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-09-09 03:22:26 Re: Proposal: Solving the "Return proper effected tuple
Previous Message Steve Howe 2002-09-09 03:19:00 Re: Proposal: Solving the "Return proper effected tuple count