Re: Proposal: RETURNING primary_key()

Dave,

* Dave Cramer (pg(at)fastcrypt(dot)com) wrote:
> On 3 April 2016 at 21:56, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > * Dave Cramer (pg(at)fastcrypt(dot)com) wrote:
> > > On 3 April 2016 at 15:35, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > > > Not generally much of a JDBC user myself, but the inability to avoid
> > > > polling for LISTEN notifications is a pretty big annoyance, which I
> > just
> > > > ran into with a client. I understand that -ng has a way to avoid that,
> > > > even for SSL connections.
> > >
> > > Yes, it is a custom api. Easy enough to add. Is this something of
> > interest ?
> >
> > I'd say that there is definite interest in this and there's a lot of
> > conversation about it on the interwebs (stackoverflow, etc).
> >
> > My understanding is that the problem is actually with the SSL library
> > that the JDBC driver uses and that it basically lies about if there are
> > bytes available for reading (claiming that there never is by always
> > returning zero). The -ng driver, as I understand it, uses a newer SSL
> > library which better supports asking if there are bytes available to
> > read.
>
> Hmmm. that complicates things...
>
> Async notification is the easier part, I wasn't aware that the ssl library
> had this problem though

Right. It's not sufficient to simply poll the JDBC driver to see if
there are notifications currently, you have to actually generate traffic
between the client and the server, to force the driver to read from the
SSL library and discover any notifications which have arrived from the
server. That can be done by issuing an all-whitespace command, which
the server will respond to with an EmptyQueryMessage (iirc), but you
can't simply have the Java side sit in a select() loop or similar
waiting for notifications to arrive.

Thanks!

Stephen