Re: Built-in plugin for logical decoding output

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

In response to

Responses

Browse pgsql-hackers by date

  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