From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | Alvaro Hernandez <aht(at)ongres(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Euler Taveira <euler(at)timbira(dot)com(dot)br>, Gregory Brail <gregbrail(at)google(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Built-in plugin for logical decoding output |
Date: | 2017-09-26 07:03:23 |
Message-ID: | CAMsr+YFS+-T3czr3oVL4Kr+zpB2+Z33ncQQNdK8zz3q=qaDOOQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 26 September 2017 at 14:08, Alvaro Hernandez <aht(at)ongres(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2017-09-26 07:16:11 | Re: Setting pd_lower in GIN metapage |
Previous Message | Michael Paquier | 2017-09-26 06:45:23 | Re: coverage analysis improvements |