Horton

Re: Command Triggers, patch v11

Dimitri Fontaine <dimitri@2ndquadrant.fr>

View thread
From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
To: Thom Brown <thom@linux.com>
Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>, Robert Haas <robertmhaas@gmail.com>, Kevin Grittner <Kevin.Grittner@wicourts.gov>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2012-03-03T14:34:59Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix SPGiST vacuum algorithm to handle concurrent tuple motion properly.

  2. Remove useless const qualifier

  3. Make executor's SELECT INTO code save and restore original tuple receiver.

Thom Brown <thom@linux.com> writes:
> problem.  It was the DROP COMMAND TRIGGER statement that garnered
> comment, as it makes more sense to drop the entire trigger than
> individual commands for that trigger.

What you're saying here is that a single command could have more than
one command attached to it, and what I understand Tom, Robert and Kevin
are saying is that any given command trigger should only be attached to
a single command.

If we wanted to be more consistent we would need to have a way to attach
the same trigger to both BEFORE and AFTER the command, as of now you
need two triggers here.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support