2017-09-23 14:01 GMT-03:00 Alvaro Hernandez <aht@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