2017-09-23 14:01 GMT-03:00 Alvaro Hernandez <a...@ongres.com>: > However, AFAIK, AWS's DMS uses it for production purposes (see > http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html). > It seems a bad idea. AFAICS test_decoding was not designed to be a ready-for-production plugin. It is just a proof of concept for logical decoding.
> I would be happy to see another logical decoding plugin into core > starting on 11. However, this also poses a bit of a challenge for middleware > implementors: you need to support one for 9.4-9.5 (test_decoding), another > for 10 (pgoutput) and maybe another for 11 onwards. The idea of asking users > to install a binary plugin is very unsexy, so these are the options > available. > wal2json works for 9.4+ (besides the WAL messages I committed a month ago). Since this boat was already shipped we can arrange some packages for 9.4-10 (an external project) and ask vendors to support the backward-compatible plugin. The middleware implementor will have to support this new plugin format. Being JSON a widespread format, it is easier to refactor the code to parse JSON. > However, having said that, and while json is a great output format for > interoperability, if there's a discussion on which plugin to include next, > I'd also favor one that has some more compact representation format (or that > supports several formats, not only json). > We could certainly extend pgoutput to support more than one format (like pglogical did AFAIR), however, we wouldn't reuse code (different formats) and will have a fat plugin (I don't foresee a plugin using different formats in the same connection. It is difficult to coordinate a change like that having only one-way communication). -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
