Re: Event Triggers: adding information

On Thu, Jan 17, 2013 at 8:33 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> I have no problem requiring C code to use the even data, be it via hooks
> or via C functions called from event triggers. The problem I have with
> putting in some hooks is that I doubt that you can find sensible spots
> with enough information to actually recreate the DDL for a remote system
> without doing most of the work for command triggers.

It should be noted that the point of KaiGai's work over the last three
years has been to solve exactly this problem. Well, KaiGai wants to
check security rather than do replication, but he wants to be able
grovel through the entire node tree and make security decisions based
on stuff core PG doesn't care about, so in effect the requirements are
identical. Calling the facility "event triggers" rather than "object
access hooks" doesn't make the underlying problem any easier to solve.
I actually believe that the object access hook stuff is getting
pretty close to a usable solution if you don't mind coding in C, but
I've had trouble convincing anyone else of that.

I find it a shame that it hasn't been taken more seriously, because it
really does solve the same problem. sepgsql, for example, has no
trouble at all checking permissions for dropped objects. You can't
call procedural code from the spot where we've got that hook, but you
sure can call C code, with the usual contract that if it breaks you
get to keep both pieces. The CREATE stuff works fine too. Support
for ALTER is not all there yet, but that's because it's a hard
problem.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company