Re: Changeset Extraction v7.6.1 - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: Changeset Extraction v7.6.1 |
Date | |
Msg-id | CA+TgmoZGLKJ1GsBAGQw5jEX9_GhwNS0R4p2LN9CZ9=B=CEQEuw@mail.gmail.com Whole thread Raw |
In response to | Re: Changeset Extraction v7.6.1 (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Changeset Extraction v7.6.1
(Peter Geoghegan <pg@heroku.com>)
Re: Changeset Extraction v7.6.1 (Andres Freund <andres@2ndquadrant.com>) |
List | pgsql-hackers |
On Mon, Feb 17, 2014 at 9:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> 3. As this feature is proposed, the only plugin we'll ship with 9.4 is >> a test_decoding plugin which, as its own documentation says, "doesn't >> do anything especially useful." What exactly do we gain by forcing >> users who want to make use of these new capabilities to write C code? > > TBH, if that's all we're going to ship, I'm going to vote against > committing this patch to 9.4 at all. Let it wait till 9.5 when we > might be able to build something useful on it. To point out just > one obvious problem, how much confidence can we have in the APIs > being right if there are no usable clients? Even if they're right, > what benefit do we get from freezing them one release before anything > useful is going to happen? I actually have a lot of confidence that the APIs are almost entirely right, except maybe for the snapshot-related stuff and possibly one or two other minor details. And I have every confidence that 2ndQuadrant is going to put out decoding modules that do useful stuff. I also assume Slony is going to ship one at some point. EnterpriseDB's xDB replication server will need one, so someone at EDB will have to go write that. And if Bucardo or Londiste want to use this infrastructure, they'll need their own, too. What I don't understand is why it's cool to make each of those replication solutions bring its own to the table. I mean if they want to, so that they can generate exactly the format they want with no extra overhead, sure, cool. What I don't understand is why we're not taking the test_decoding module, polishing it up a little to produce some nice, easily machine-parseable output, calling it basic_decoding, and shipping that. Then people who want something else can build it, but people who are happy with something basic will already have it. What I actually suspect is going to happen if we ship this as-is is that people are going to start building logical replication solutions on top of the test_decoding module even though it explicitly says that it's just test code. This is *really* cool technology and people are *hungry* for it. But writing C is hard, so if there's not a polished plugin available, I bet people are going to try to use the not-polished one. I think we try to get out ahead of that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
pgsql-hackers by date: