Re: Proposal: Solving the "Return proper effected tuple

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Proposal: Solving the "Return proper effected tuple
Дата
Msg-id 200209090321.g893LB520957@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: Proposal: Solving the "Return proper effected tuple count from complex commands [return]" issue  (Steve Howe <howe@carcass.dhs.org>)
Ответы Re: Proposal: Solving the "Return proper effected tuple count from complex commands [return]" issue  (Steve Howe <howe@carcass.dhs.org>)
Список 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 по дате отправления:

Предыдущее
От: Steve Howe
Дата:
Сообщение: Re: Proposal: Solving the "Return proper effected tuple count
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Proposal: Solving the "Return proper effected tuple