Re: Built-in plugin for logical decoding output

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Hernandez <aht(at)ongres(dot)com>
Cc: Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Euler Taveira <euler(at)timbira(dot)com(dot)br>, Gregory Brail <gregbrail(at)google(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Built-in plugin for logical decoding output
Date: 2017-09-25 17:26:42
Message-ID: 19377.1506360402@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Hernandez <aht(at)ongres(dot)com> writes:
> In my opinion, logical decoding plugins that don't come with core
> are close to worthless (don't get me wrong):

> - They very unlikely will be installed in managed environments (an area
> growing significantly).
> - As anything that is not in core, raises concerns by users.
> - Distribution and testing are non-trivial: many OS/archs combinations.

The problem with this type of argument is that it leads directly to the
conclusion that every feature users want must be in core. We can't
accept that conclusion, because we simply do not have the manpower or
infrastructure to maintain a kitchen-sink, Oracle-sized code base.
I think we're already more or less at the limit of the feature set we can
deal with :-(. The entire point of the output-plugin design was to allow
useful replication stuff to be done outside of core; we need to make use
of that. (If that means we need better docs, then yeah, we'd better get
that part done.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2017-09-25 17:31:26 Re: Built-in plugin for logical decoding output
Previous Message Joshua D. Drake 2017-09-25 17:26:20 Re: Built-in plugin for logical decoding output