On 3 April 2016 at 15:35, Stephen Frost <sfr...@snowman.net> wrote: > * Dave Cramer (p...@fastcrypt.com) wrote: > > On 9 March 2016 at 20:49, Craig Ringer <cr...@2ndquadrant.com> wrote: > > > > > On 10 March 2016 at 00:41, Igal @ Lucee.org <i...@lucee.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 da...@postgresintl.com www.postgresintl.com
