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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
