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

From Alvaro Herrera
Subject Re: manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. "Upsert" logic)
Date
Msg-id 20090907224527.GQ8894@alvh.no-ip.org
Whole thread Raw
In response to Re: manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. "Upsert" logic)  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. "Upsert" logic)
List pgsql-hackers
Pavel Stehule escribió:
> 2009/9/7 Alvaro Herrera <alvherre@commandprompt.com>:

> > 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?

As far as I can tell it's not possible to do better without letting the
user put their hands on the tag.  The problem is figuring out what
command should determine the tag.

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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [Pgbuildfarm-members] Snow Leopard bison/flex build problem
Next
From: Tom Lane
Date:
Subject: Re: [Pgbuildfarm-members] Snow Leopard bison/flex build problem