Re: Last gasp - Mailing list pgsql-hackers

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:
> > On Thu, Apr 5, 2012 at 7:00 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> >> On Thu, Apr 5, 2012 at 1:28 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> >>> These patches aren't marked with a committer
> >>>
> >>> FK arrays
> >>> ECPG fetch
> >>> foreign stats
> >>> command triggers
> >>> check function
> >>> parallel pg_dump
> >>>
> >>> Does that mean myself or others should be claiming them for commit/reject?
> >>
> >> I've been right in the middle of the command triggers stuff, so I
> >> suppose I would pick that up for commit if it were ready, but there
> >> hasn't been a new version this week unless I've missed it, and even if
> >> the new version arrived right this minute, I don't think I or anyone
> >> else can do a good job committing a patch of that size in the time
> >> remaining.  So I think it's time to formally put that one out of its
> >> misery.
> >
> > 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.

>  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
>