Re: Last gasp - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Last gasp
Date
Msg-id 1333652322.31440.55.camel@hvost
Whole thread Raw
In response to Re: Last gasp  (Hannu Krosing <hannu@krosing.net>)
Responses Re: Last gasp  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, 2012-04-05 at 20:46 +0200, Hannu Krosing wrote:
> On Thu, 2012-04-05 at 14:27 -0400, Robert Haas wrote:
> > On Thu, Apr 5, 2012 at 2:17 PM, Simon Riggs <simon@2ndquadrant.com> wrote:

...
> > > I think doing so will cause substantial misery for many users. I find
> > > it hard to believe that such a simple concept hasn't managed to
> > > produce some workable subset after months of work.
> > 
> > I am not interested in relitigating on this thread what has already
> > been extensively discussed nearby.  Dimitri and I agreed on numerous
> > changes to try to make the behavior sane,
> 
> To me it looked like the scope of the patch started to suddenly expand
> exponentially a few days ago from a simple COMMAND TRIGGERS, which would
> have finally enabled trigger-based or "logical" replication systems to
> do full replication to something recursive which would attempt to cover
> all weird combinations of commands triggering other commands for which
> there is no real use-case in view, except a suggestion "don't do it" :)
> 
> The latest patch (v18) seemed quite ok for its original intended
> purpose.

Sorry, i hit "send!" too early.

Would it be possible to put some "command trigger hooks" in a few
strategic places so that some trigger-like functionality could be loaded
at run time, mainly with a view of writing DDL replication
'non-triggers' , mostly based on current v18 code, but of course without
all the nice CREATE TRIGGER syntax ?

perhaps created with a pg_create_command_trigger(...)

that is something in the line of how Full Text Indexing was done for a
long time.

> >  and those changes were
> > suggested and agreed to for good reason.  We didn't agree on every
> > point, of course, but we did agree on most of it, and there is no
> > patch that implements what was agreed.  Even if there were, there is
> > not time to review and commit a heavily revised version of a >1000
> > line patch before tomorrow, and any suggestion to the contrary is just
> > plain wrong.
> > 
> > -- 
> > Robert Haas
> > EnterpriseDB: http://www.enterprisedb.com
> > The Enterprise PostgreSQL Company
> > 
> 
> 
> 




pgsql-hackers by date:

Previous
From: Michael Meskes
Date:
Subject: Re: Last gasp
Next
From: Andrew Dunstan
Date:
Subject: Re: Last gasp