On 2014-02-17 21:35:23 -0500, Robert Haas wrote: > 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.
Because every project is going to need their own plugin *anyway*. Londiste, slony sure are going to ignore changes to relations they don't need. Querying their own metadata. They will want compatibility to the earlier formats as far as possible. Sometime not too far away they will want to optionally support binary output because it's so much faster. There's just not much chance that either of these will be able to agree on a format short term. So, possibly we could agree to something that consumers *outside* of replication could use. > 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. I really hope there will be nicer ones by the time 9.4 is released. Euler did send in a json plugin http://archives.postgresql.org/message-id/52A5BFAE.1040209%2540timbira.com.br , but there hasn't too much feedback yet. It's hard to start discussing something that needs a couple of patches to pg before you can develop your own patch... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers