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

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Mark Reid <mark(at)markreid(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. "Upsert" logic)
Date: 2009-09-07 21:42:10
Message-ID: 20090907214210.GP8894@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs pgsql-hackers

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.

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.

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Pavel Stehule 2009-09-07 22:23:13 Re: manually setting the command tag (was Re: 8.4: suppress_redundant_updates trigger vs. "Upsert" logic)
Previous Message Tom Lane 2009-09-07 17:28:11 Re: no refentry in acronyms.sgml?

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-09-07 22:08:25 Re: [Pgbuildfarm-members] Snow Leopard bison/flex build problem
Previous Message Dave Page 2009-09-07 20:41:28 Re: [Pgbuildfarm-members] Snow Leopard bison/flex build problem