Horton

Re: Command Triggers, patch v11

Dimitri Fontaine <dimitri@2ndquadrant.fr>

View thread
From: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Dimitri Fontaine <dimitri@2ndquadrant.fr>, pgsql-hackers@postgresql.org
Date: 2012-03-14T08:27:08Z
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 Tue, Mar 13, 2012 at 5:06 PM, Andres Freund <andres@anarazel.de> wrote:
>> Generally, uppon rereading, I have to say that I am not very happy with the
>> decision that ANY triggers are fired from other places than the specific
>> triggers. That seams to be a rather dangerous/confusing route to me.
>
> I agree. I think that's a complete non-starter.

Ok, well, let me react in 2 ways here:

 A. it's very easy to change and will simplify the code
 B. it's been done this way for good reasons (at the time)

Specifically, I've been asked to implement the feature of blocking all
and any DDL activity on a machine in a single command, and we don't have
support for triggers on all commands (remember shared objects).

Now, as I've completed support for all interesting commands the
discrepancy between what's supported in the ANY case and in the specific
command case has reduced. If you're saying to nothing, that's good news.

Also, when calling the user's procedure from the same place in case of an
ANY command trigger or a specific one it's then possible to just hand
them over the exact same set of info (object id, name, schema name).

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