Horton

Re: Command Triggers, patch v11

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Thom Brown <thom@linux.com>, Dimitri Fontaine <dimitri@2ndquadrant.fr>, pgsql-hackers@postgresql.org, Andres Freund <andres@anarazel.de>
Date: 2012-03-09T15:05:05Z
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.

Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Mar 9, 2012 at 9:22 AM, Thom Brown <thom@linux.com> wrote:
>> Sorry, I meant any command trigger. It's because none of the commands
>> can be run on a standby, so the triggers don't seem appropriate.

> I'm not convinced.  Right now, it's fairly useless - all the triggers
> could possibly do is throw an error, and an error is going to get
> thrown anyway, so it's only a question of which error message the user
> will see.  But we discussed before the idea of adding a capability for
> BEFORE triggers to request that the actual execution of the command
> get skipped, and then it's possible to imagine this being useful.

Um, surely the "you can't do that in a read-only session" error is going
to get thrown long before the command trigger could be called?

			regards, tom lane