On Thu, Jan 7, 2016 at 4:50 PM, Craig Ringer <cr...@2ndquadrant.com> wrote: > On 7 January 2016 at 01:17, Peter Eisentraut <pete...@gmx.net> wrote: >> On 12/22/15 4:55 AM, Craig Ringer wrote: >> 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. > > Again, I disagree. I think you're looking at this way too narrowly. > > I find it quite funny, actually. Here we go and produce something that's a > nice re-usable component that other people can use in their products and > solutions ... and all anyone does is complain that the other part required > to use it as a canned product isn't posted yet (though it is now). But with > BDR all anyone ever does is complain that it's too tightly coupled to the > needs of a single product and the features extracted from it, like > replication origins, should be more generic and general purpose so other > people can use them in their products too. Which is it going to be?
As far as I can see, this patch is leveraging the current infrastructure in core, logical decoding to convert the data obtained as a set JSON blobs via a custom protocol. Its maintenance load looks minimal, that's at least a good thing. > It would be helpful if you could take a step back and describe what *you* > think logical replication for PostgreSQL should look like. You clearly have > a picture in mind of what it should be, what requirements it satisfies, etc. > If you're going to argue based on that it'd be very helpful to describe it. > I might've missed some important points you've seen and you might've > overlooked issues I've seen. Personally, if I would put a limit of what should be in-core, or what should be logical replication from the core prospective, that would be just to give to potential consumers (understand plugins here) of this binary data (be it pg_ddl_command or what the logical decoding context offers) a way to access it and then to allow those plugins to change this binary data into something that is suited to it, and have simple tools and example to test those things without relying on anything external. test_decoding and test_ddl_deparse cover that already. What I find a bit disturbing regarding this patch is: why would a JSON representation be able to cover all kinds of needs? Aren't other replication solution going to have their own data format and their own protocol with different requirements? Considering that this module could have a happier life if managed independently. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
