Re: manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. "Upsert" logic) - Mailing list pgsql-hackers

From decibel
Subject Re: manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. "Upsert" logic)
Date
Msg-id F8D6DF33-4AE9-47E4-8D3E-58DB186C72A1@decibel.org
Whole thread Raw
In response to Re: manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. "Upsert" logic)  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: CTE bug?
Next
From: David Fetter
Date:
Subject: Re: Any interest in buildfarm a member using Apple's llvm-gcc-4.2 or clang?