On 26 September 2017 at 14:08, Alvaro Hernandez <aht@ongres.com> wrote:
OK, let me try to do that. I believe data integration is a priority.
Definitely agree so far.
- If you want to develop your own output plugin, then your market is reduced as you have to exclude all the managed solutions (until, and only if, you would convince them to include your plugin... highly unlikely, very difficult). And probably another % of enterprise environments which will hesitate to link your own plugin to the running production database. Last but not least, you need to compile and test (and testing this is far from easy) on multiple OSes/architectures.
Right. You probably don't want one output plugin per application.
This doesn't mean it has to be in-core, just flexible and share-able by many, and adopted by cloud vendors. Like say PostGIS.
- If you stick to in-core plugins, then you need to support at least three different output formats if you want to support 9.4+: test_decoding (and pray it works!), pgoutput, and the "new" in-core plugin that was proposed at the beginning of this thread, if that would see the light.
The only practical way will IMO be to have whatever new plugin it also have an out-of-core version maintained for older Pg versions, where it can be installed.
But only in-core plugins help for general-purpose solutions.
I still don't agree there. If there's enough need/interest/adoption you can get cloud vendors on board, they'll feel the customer pressure. It's not our job to create that pressure and do their work for them.
I see nothing wrong with a plugin starting off out of core and being adopted+adapted later, assuming it's done well.
That said, I'm all in favour of a generic json output plugin that shares infrastructure with logical replication, so people who are on inflexible environments have a fallback option. I just don't care to write it.