Re: [HACKERS] Built-in plugin for logical decoding output - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: [HACKERS] Built-in plugin for logical decoding output
Date
Msg-id CAMsr+YFG1ZRkVGu35dAbpr7GL-Y7DxCWxK5Lg7FVfDk-cL9ugA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Built-in plugin for logical decoding output  (Alvaro Hernandez <aht@ongres.com>)
Responses Re: [HACKERS] Built-in plugin for logical decoding output  (Alvaro Hernandez <aht@ongres.com>)
List pgsql-hackers
On 26 September 2017 at 15:26, Alvaro Hernandez <aht@ongres.com> wrote:

    That's better than nothing. But as much as interoperable json may be, people still need to talk the (binary) replication protocol to use it.

No, they don't. 

They can use the SQL interface to logical decoding.

We could enhance that with a few small changes to make it a lot more useful too. Most importantly, allow a long-polling model, where you can wait if there's nothing to consume rather than getting an immediate empty result-set.

I expect the walsender protocol to be dealt with by client drivers, not user applications, much like you never really deal with the regular libpq protocol in your app. PgJDBC and psycopg2 already support it. It'd be nice if libpq offered some helper interfaces for C apps, and I'd help review any such patch.

Nothing against binary output, but as you noted, we can likely use pgoutput for that to some extent at least. I think the pressing need is json, going by the zillion plugins out there for it.

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

pgsql-hackers by date:

Previous
From: Mark Kirkwood
Date:
Subject: Re: [HACKERS] tablespaces inside $PGDATA considered harmful
Next
From: Amit Langote
Date:
Subject: Re: [HACKERS] Optimise default partition scanning while adding newpartition