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

From Pavel Stehule
Subject Re: manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. "Upsert" logic)
Date
Msg-id 162867790909072055i795f4684w3de6ff1f26454113@mail.gmail.com
Whole thread Raw
In response to Re: manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. "Upsert" logic)  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
2009/9/8 Alvaro Herrera <alvherre@commandprompt.com>:
> Tom Lane escribió:
>> 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?
>
> We would allow the user to set a policy.  This provides the mechanism
> for doing it.  Right now there is no mechanism at all and we fail to do
> anything.
>
>> I don't think that "put it on the user's shoulders" is a good solution.
>
> Is there a better idea?

we should to count rows on storage level  - and then (via GUC) we
should to return global count or table count.

???



>
> --
> Alvaro Herrera                                http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
>


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: More Snow Leopard fun: multiarch problems while building plperl
Next
From: Tom Lane
Date:
Subject: Re: [Pgbuildfarm-members] Snow Leopard bison/flex build problem