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

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. "Upsert" logic)
Дата
Msg-id 20090907224527.GQ8894@alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. "Upsert" logic)  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы 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
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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [Pgbuildfarm-members] Snow Leopard bison/flex build problem
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [Pgbuildfarm-members] Snow Leopard bison/flex build problem