Re: manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. "Upsert" logic)

Поиск
Список
Период
Сортировка
От decibel
Тема Re: manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. "Upsert" logic)
Дата
Msg-id F8D6DF33-4AE9-47E4-8D3E-58DB186C72A1@decibel.org
обсуждение исходный текст
Ответ на Re: manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. "Upsert" logic)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Sep 7, 2009, at 6:10 PM, Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> Pavel Stehule escribió:
>>> Isn't better to solve the the correct diagnostics for INSTEAD
>>> rules or triggers?
>
>> As far as I can tell it's not possible to do better without
>> letting the
>> user put their hands on the tag.
>
> And how is the user going to do better?  For example, what if there
> are
> two triggers trying to set the result, perhaps because two different
> commands have been generated by DO ALSO rules?


It depends on what the user is trying to accomplish. If the ALSO rule
is just doing auditing type stuff, then they probably don't want that
included in the result.

I don't see this is being different from having to get the rules
correct in the first place; all we're doing here is adding the
ability to return a meaningful result from the rules back to the client.

BTW, the real-world case we have are updatable views on top of a
union. In this case we'd want the result to reflect the updates that
occurred in all the tables, not just in the last table in the rule.
--
Decibel!, aka Jim C. Nasby, Database Architect  decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: CTE bug?
Следующее
От: David Fetter
Дата:
Сообщение: Re: Any interest in buildfarm a member using Apple's llvm-gcc-4.2 or clang?