Re: Binary support for pgoutput plugin

Dave Cramer

On Fri, 14 Jun 2019 at 14:36, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
wrote:

> On Wed, Jun 12, 2019 at 10:35:48AM -0400, Dave Cramer wrote:
> >On Mon, 10 Jun 2019 at 07:49, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>
> >wrote:
> >
> >> Hi,
> >>
> >> On 10/06/2019 13:27, Dave Cramer wrote:
> >> > So back to binary output.
> >> >
> >> > From what I can tell the place to specify binary options would be in
> the
> >> > create publication and or in replication slots?
> >> >
> >> > The challenge as I see it is that the subscriber would have to be able
> >> > to decode binary output.
> >> >
> >> > Any thoughts on how to handle this? At the moment I'm assuming that
> this
> >> > would only work for subscribers that knew how to handle binary.
> >> >
> >>
> >> Given that we don't need to write anything extra to WAL on upstream to
> >> support binary output, why not just have the request for binary data as
> >> an option for the pgoutput and have it chosen dynamically? Then it's the
> >> subscriber who asks for binary output via option(s) to
> START_REPLICATION.
> >>
> >
> >If I understand this correctly this would add something to the
> CREATE/ALTER
> >SUBSCRIPTION commands in the WITH clause.
> >Additionally another column would be required for pg_subscription for the
> >binary option.
> >Does it make sense to add an options column which would just be a comma
> >separated string?
> >Not that I have future options in mind but seems like something that might
> >come up in the future.
> >
>
> I'd just add a boolean column to the catalog. That's what I did in the
> patch adding support for streaming in-progress transactions. I don't think
> we expect many additional parameters, so it makes little sense to optimize
> for that case.
>

Which is what I have done. Thanks

I've attached both patches for comments.
I still have to add documentation.

Regards,

Dave