Re: JDBC gripe list

On 03/25/2011 04:07 PM, Simon Riggs wrote:
> On Fri, Mar 25, 2011 at 12:35 AM, Dave Cramer<pg@fastcrypt.com>  wrote:
>> Just got back from pgeast. Seems everyone seems to have a gripe about
>> the JDBC driver.
>>
>> My sense is that for basic read/write/update/delete the driver works
>> just fine. However I'd like to compile a list of everyone's gripe.
>
> Funny that, I just got back from a different conference where people
> were griping about it also.
>
> Didn't get a detailed list but numbers of less impressed people all
> active Postgres users and supporters.

Personally, I think the JDBC driver is fine. It's not perfect, but I
hardly feel justified "demanding" a perfect driver when I haven't
contributed anything to its creation. People appear to be very happy to
complain, but rather less willing to knuckle down and help!

I'm not using the JDBC driver heavily and generally find that it does
the job quite well. Also, a least I put in the effort to fix one issue -
the core code's handling of client certs requests when multiple certs
are in the Keystore. Not that anyone seems to _use_ X.509 client
certificates...

The only actual issues I've run into, none of which were exactly
showstoppers though all of which cost me significant time finding
workarounds, are:

- (biggest problem) The JDBC driver interacts poorly with PostgreSQL 8.3
and above's removal of implicit casts when using extended Pg types,
user-defined types, etc. It's often desirable to represent a type in
Java as String, BigDecimal, etc, though it's backed by a domain or a
custom type on the Pg side. The most painful time I've had with this was
working with Pg's xml type, which I needed to represent Java-side as a
string. This is ... painful ... with PgJDBC, especially if you're using
a midlayer like JPA2 so you can't use setObject(...) directly. When it's
a user-defined type you can define implicit casts, but it's IMO
unreasonable to have to go messing with the system catalog just to be
able to convert from xml <-> string for example.

Try writing a simple test program that handles the 'xml' type from
Hibernate or JPA to see what I mean.

IMO the server shouldn't be being so strict about implicit conversions
*from* string to certain string-like types like xml. Since that's
apparently not going to change, it'd be wonderful if the JDBC driver had
a way to detect the destination types and send data with the right type
when passed a string representation of the type.



- Inability to reliably receive notifications without risking blocking.
It's not possible to check for notifications w/o risking blocking on SSL
connections, and there's no way to ask the driver if the connection is
SSL or request that it only check for notifications if it can do so
safely without blocking indefinitely. Needs a new notification checking
method that, if it cannot guarantee that it's using a non-ssl
connection, sends a minimum client/server round trip and reads the response.


- Notifications, warnings, notices, etc can flood the receive buffer,
leading to deadlock if progress requires that more data be sent before a
read is attempted. This has been widely discussed, and the general
consensus appears to be that a worker thread for the driver would be
required in order to provide a general and reliable solution.



--
Craig Ringer