Re: Proposal: RETURNING primary_key()

On 3 April 2016 at 15:35, Stephen Frost <sfrost(at)snowman(dot)net> wrote:

> * Dave Cramer (pg(at)fastcrypt(dot)com) wrote:
> > On 9 March 2016 at 20:49, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> >
> > > On 10 March 2016 at 00:41, Igal @ Lucee.org <igal(at)lucee(dot)org> wrote:
> > >
> > >> On 3/8/2016 5:12 PM, Craig Ringer wrote:
> > >>
> > >>> One of the worst problems (IMO) is in the driver architecture its
> self.
> > >>> It attempts to prevent blocking by guestimating the server's send
> buffer
> > >>> state and its recv buffer state, trying to stop them filling and
> causing
> > >>> the server to block on writes. It should just avoid blocking on its
> own
> > >>> send buffer, which it can control with confidence. Or use some of
> Java's
> > >>> rather good concurrency/threading features to simultaneously consume
> data
> > >>> from the receive buffer and write to the send buffer when needed,
> like
> > >>> pgjdbc-ng does.
> > >>>
> > >>
> > >> Are there good reasons to use pgjdbc over pgjdbc-ng then?
> > >>
> > >>
> > > Maturity, support for older versions (-ng just punts on support for
> > > anything except new releases) and older JDBC specs, completeness of
> support
> > > for some extensions. TBH I haven't done a ton with -ng yet.
> >
> > I'd like to turn this question around. Are there good reasons to use -ng
> > over pgjdbc ?
>
> 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 ?

Dave Cramer

davec(at)postgresintl(dot)com
www.postgresintl.com