On 12/22/15 4:55 AM, Craig Ringer wrote:
> I'm a touch frustrated by that, as a large part of the point of
> submitting the output plugin separately and in advance of the downstream
> was to get attention for it separately, as its own entity. A lot of
> effort has been put into making this usable for more than just a data
> source for pglogical's replication tools.
I can't imagine that there is a lot of interest in a replication tool
where you only get one side of it, no matter how well-designed or
general it is. Ultimately, what people will want to do with this is
replicate things, not muse about its design aspects. So if we're going
to ship a replication solution in PostgreSQL core, we should ship all
the pieces that make the whole system work.
Also, I think there are two kinds of general systems: common core, and
all possible features. A common core approach could probably be made
acceptable with the argument that anyone will probably want to do things
this way, so we might as well implement it once and give it to people.
In a way, the logical decoding interface is the common core, as we
currently understand it. But this submission clearly has a lot of
features beyond just the basics, and we could probably go through them
one by one and ask, why do we need this bit? So that kind of system
will be very hard to review as a standalone submission.