Re: Proposal: Solving the "Return proper effected tuple
От | Joe Conway |
---|---|
Тема | Re: Proposal: Solving the "Return proper effected tuple |
Дата | |
Msg-id | 3D7C0D75.90805@joeconway.com обсуждение исходный текст |
Ответ на | 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
Re: Proposal: Solving the "Return proper effected tuple count |
Список | 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 по дате отправления: