Collectors versus Flow.Subscriber

[Alexander Kjäll]

It can maybe be thought of as an row sequence with one row per event, and
it should be possible to be represented as a RowOperation.

But I was more thinking about back pressure, the collector interface
doesn't really allow the implementation to signal to the driver that it
can't handle the rate of traffic, and a busy event generator might
overwhelm the consumer. This might maybe be a problem with normal queries
also?

I haven't done any testing of this, and I don't have any concrete code that
demonstrates the problem. I can revisit this topic later when I have
something more concrete to show and talk about.

best regards
Alexander Kjäll

Den mån 30 apr. 2018 kl 18:06 skrev Douglas Surber <
douglas.surber at oracle.com>:

> We haven’t discussed much aside from ANSI SQL. I don’t know anything
about postgresql logical decoding. Is it a row sequence? If so then either
RowOperation or RowProcessorOperation should do fine. If it returns a
result that doesn’t map to an ANSI SQL result then it would require a
vendor specific extension.

> Douglas

> > On Apr 28, 2018, at 1:21 PM, Alexander Kjäll <alexander.kjall at gmail.com>
wrote:
> >
> > Hi
> >
> > I have been poking around writing an implementation of ADBA for
postgresql
> > and have a question regarding how 'endless' datastreams should be
handled.
> >
> > To take a concrete case is the feature in postgresql that's called
logical
> > decoding, it lets a user subscribe to the replication stream from the
> > database.
> >
> > This isn't a stream that has an end, and by that account it doesn't
really
> > in the stream model with collectors and would maybe fit better with the
> > Flow.Subscriber model.
> >
> > Have this usecase been considered and is there a way to implement this
that
> > I haven't seen?
> >
> > best regards
> > Alexander Kjäll