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

2009/9/7 Alvaro Herrera <alvherre(at)commandprompt(dot)com>:
> Mark Reid wrote:
>
>> It'll similarly break any code where a result of "UPDATE 0" is assumed to
>> indicate that the record does not exist.
>
> I wonder if this could be helped if the trigger had a way of overriding
> the emitted command tag.
>
> There are countless reports of trouble because somebody has an INSTEAD
> rule in the table, and the tag emits something that's not quite
> acceptable for some outer software layer.  The problem is that there's
> no way at all to make the command tag behave!
>
> For example, we could offer a new SPI function, say SPI_settag(), which
> sets the command tag string.  PL/pgSQL could expose this via a new
> command, for example COMMANDTAG.

Isn't better to solve the the correct diagnostics for INSTEAD rules or triggers?

Pavel

>
> So if there's a function that is used in a INSTEAD rule for (say) an
> UPDATE, this function would finish with COMMANDTAG 'UPDATE num' and make
> the external framework happy.
>
> --
> Alvaro Herrera                                http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>