On Mon, Feb 17, 2014 at 6:35 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> 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.
Tom made a comparison with FDWs, so I'll make another. The Multicorn
module made FDW authorship much more accessible by wrapping it in a
Python interface, I believe with some success. I don't want to stand
in the way of building a fully-featured test_decoding module, but I
think that those that would misuse test_decoding as it currently
stands can be redirected to a third-party wrapper. As you say, it's
pretty cool stuff, so it seems likely that someone will build one for
us.
--
Peter Geoghegan
