Re: Proposal: Solving the "Return proper effected tuple
От | Bruce Momjian |
---|---|
Тема | Re: Proposal: Solving the "Return proper effected tuple |
Дата | |
Msg-id | 200209100224.g8A2OJr04571@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Proposal: Solving the "Return proper effected tuple (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Proposal: Solving the "Return proper affected tuple
|
Список | pgsql-hackers |
Peter Eisentraut wrote: > Steve Howe writes: > > > Here are the proposals for solutioning the "Return proper effected > > tuple count from complex commands [return]" issue as seen on TODO. > > > > Any comments ?... This is obviously open to voting and discussion. > > We don't have a whole lot of freedom in this; this area is covered by the > SQL standard. The major premise in the standard's point of view is that > views are supposed to be transparent. That is, if > > SELECT * FROM my_view WHERE condition; > > return N rows, then a subsequently executed > > UPDATE my_view SET ... WHERE condition; > > returns an update count of N, no matter what happens behind the scenes. I > don't think this matches Tom Lane's view exactly, but it's a lot closer > than your proposal. Oh, this is bad news. The problem we have is that rules don't distinguish the UPDATE on the underlying tables of the rule from other updates that may appear in the query. If we go with Tom's idea and total just UPDATE's, we will get the right answer when there is only one UPDATE in the ruleset. -- 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 по дате отправления: