Re: Event Triggers: adding information

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Event Triggers: adding information
Date: 2013-01-18 03:01:25
Message-ID: 20130118030124.GI3074@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2013-01-17 21:48:01 -0500, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > 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.

> "most of the work"? No, I don't think so. Here's the thing that's
> bothering me about that: if the use-case that everybody is worried about
> is replication, then triggers of any sort are the Wrong Thing, IMO.

> The difference between a replication hook and a trigger is that a
> replication hook has no business changing any state of the local system,
> whereas a trigger *has to be expected to change the state of the local
> system* because if it has no side-effects you might as well not bother
> firing it. And the fear of having to cope with arbitrary side-effects
> occuring in the midst of DDL is about 80% of my angst with this whole
> concept.

I *personally* would be *very* happy to get the capability to do two
things:
a) get enough information to replicate DDL to another system
b) raise an error that aborts the current action

Imo b) fits well enough with not allowing arbitrary side effects.

> If we're only interested in replication, let's put in some hooks whose
> contract does not allow for side-effects on the local catalogs, and be
> done. Otherwise we'll be putting in man-years of unnecessary (or at
> least unnecessary for this use-case) work.

Its a thing of perspective I guess. I can't imagine a hook-ey solution,
without quite a bit of work, that gets enough information to regenerate
SQL that performs the same action on another system. ISTM that the
refactoring to make that consistently "easy" is the hard part, but I
hope I am wrong.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-01-18 03:10:21 Re: Writable Foreign Tables
Previous Message Craig Ringer 2013-01-18 02:55:39 Writable Foreign Tables