Re: Built-in plugin for logical decoding output

On 26/09/17 17:50, Craig Ringer wrote:
> On 26 September 2017 at 22:14, Magnus Hagander <magnus(at)hagander(dot)net
> <mailto:magnus(at)hagander(dot)net>> wrote:
>
>
>
> On Tue, Sep 26, 2017 at 2:16 PM, Alvaro Hernandez <aht(at)ongres(dot)com
> <mailto:aht(at)ongres(dot)com>> wrote:
>
>
>
>
>     But what about earlier versions? Any chance it could be
> backported down to 9.4? If that would be acceptable, I could
> probably help/do that...
>
>
> The likelihood is zero if you mean backported into core of earlier
> versions.
>
>
> Right. We don't add features to back branches.

    Yeah, I know the policy. But asking is free ;) and in my opinion
this would be a very good reason to have an exception, if there would be
a clear desire to have a single, unified, production quality output
plugin across all PostgreSQL versions. At least I tried ;)

>
> If you mean backported as a standalone extension that could be
> installed on a previous version, probably. I'm not sure if it
> relies on any internals not present before that would make it
> harder, but it would probably at least be possible.
>
>
> All the pub/sub stuff is new and hooked into syscache etc. So you'd be
> doing a bunch of emulation/shims using user catalogs. Not impossible,
> but probably irritating and verbose. And you'd have none of the DDL
> required to manage it, so you'd need SQL-function equivalents.
>
> I suspect you'd be better off tweaking pglogical to speak the same
> protocol as pg10, since the pgoutput protocol is an evolution of
> pglogical's protocol. Then using pglogical on older versions.

    Given all this, if I would be doing an app based on logical
decoding, I think I will stick to test_decoding for <10....

    Thanks,

    Álvaro

--

Alvaro Hernandez

-----------
OnGres