Re: Command Triggers - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Command Triggers
Date
Msg-id m2zkfi7krp.fsf@2ndQuadrant.fr
Whole thread Raw
In response to Command Triggers  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: Command Triggers  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> As proposed by Jan Wieck on hackers and discussed in Ottawa at the
> Clusters Hackers Meeting, the most (only?) workable way to ever have DDL
> triggers is to have "command triggers" instead.
[...]
> The v1 patch attached contains implementation for some commands only.

Here's a v2 which is only about cleaning up the merge from master.  The
recent DROP rework conflicted badly with the command triggers patch,
quite obviously.  I didn't reimplement DROP COMMAND TRIGGER in terms of
the new facilities yet, though.

> So, any comment on the approach before I complete the rewriting of the
> commands, the out/read funcs, and add more commands to the trigger
> support code?
>
>   https://github.com/dimitri/postgres/compare/master...command_triggers

FWIW (scheduling mainly), I don't think I'm going to spend more time on
this work until I get some comments, because all that remains to be done
is about building on top of what I've already been doing here.

Well, I'd like to implement command triggers on replica too, but baring
psql support and a bunch of commands not there yet, that's about it as
far as features go.

Oh, and have expressions rewriting from the parsetree (default, check)
actually work (rather than segfault) is still a TODO too.

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

Attachment

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Inlining comparators as a performance optimisation
Next
From: Alexander Shulgin
Date:
Subject: Re: Notes on implementing URI syntax for libpq