On 26 September 2017 at 14:08, Alvaro Hernandez <a...@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. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
