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

From Alvaro Hernandez
Subject Re: [HACKERS] Built-in plugin for logical decoding output
Date
Msg-id 8846c24f-9e8b-e1ef-40dd-24238d218b3d@ongres.com
Whole thread Raw
In response to Re: [HACKERS] Built-in plugin for logical decoding output  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers


On 26/09/17 10:55, Craig Ringer wrote:
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.

    AFAIK the SQL interface was also designed for testing, not for production use...


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.

    Oh, that's a completely different perspective! Do we have any support for long-polling style queries (not that I know of). It's indeed a cool thing: SQL queries that return "live" results as soon as they happen. I don't see this restricted to logical decoding. Actually, this is what PipelineDB, among other things, seem to do. +1 for that, but I believe it's a different story.


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.

    Fair enough.


    Álvaro


-- 

Alvaro Hernandez


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

pgsql-hackers by date:

Previous
From: Alvaro Hernandez
Date:
Subject: Re: [HACKERS] Built-in plugin for logical decoding output
Next
From: Nathan Wagner
Date:
Subject: Re: [HACKERS] Fix number skipping in to_number