Re: JDBC 4 Compliance

I fully agree with Steven's point re. the existing driver's level of
stability. I also agree that without the efforts from a few key people,
getting PostgreSQL adoption to where it is today in the Java space would
simply not have a happened. Personally I am very grateful to those people.

 From my perspective (a corporate Java developer and PostgreSQL user for
more years than I care to remember), here are my views:-

1. Stability has to be top priority. I say this on the basis that every
month that goes by, more and more organisations are either evaluating or
making a switch away from proprietary databases and onto PostgreSQL. A
great many of these are Java shops using some form of server environment
such as Tomcat, Glassfish, WebSphere etc., so access will normally be
via the JDBC Driver. To de-stabilise the existing driver in any way,
shape or form, has the potential to de-rail the adoption of PostgreSQL
in a big, big way. Do not do it!

2. To say that anything prior to Java7 is "dead" is ridiculous at this
point in time, at least in a commercial environment. In one or two
year's time however it may be different. Yes, there may be compelling
security reasons to upgrade from 6 to 7, but in an existing deployed
commercial environment happily running Java 5 or 6, you are only going
to upgrade to Java 7 if there is a very good reason to do so. I can
recall numerous examples of a "simple" Java version upgrade breaking one
or more production systems. I've just checked the very latest WebShere
offering from IBM (Version 8.5.5) and that still installs Java6 by default.

3. Yes, the current driver is not perfect, and there are several missing
features which most people have identified as being more than just a
nice to have. In particular the work on getting XA support working
correctly by Bryan Varner is something that will certainly help with
installations running high transaction rate Glassfish or WebSphere
installations and using the XA mode driver is a requirement. The big
question is how do we get these new features and major fixes into the
current driver without risk of destabilisation?

Here's my suggestion on the way forward:

1. Retain the existing driver in its current form (JDBC4), archive it
and maintain it for major fixes only. Ship this as "pg-jdbc4-stable.jar"
or similar.
2. Where feasible, start adding in features taken from the other
initiatives into the main branch and ship this as "pg-jdbc4.jar" or similar.
3. Where we have a "custom" driver (say Kevin Wooten's high performance
driver) where the driver is either not fully specification compliant, or
customised in some other manner, we keep as a separate codebase and ship
as "pg-jdbc?-????,jar". In time, where feasible, fold the code into the
main branch.

I see no problem in shipping multiple JAR libraries as several
commercial JDBC vendors are already doing this. We make them all
available with recommendations for stability being to use the "stable"
driver. If you want to try and experiment with one of the other drivers,
you can do so, we just need to document in the release the known issues
and differences to the stable driver. Environments like IBM WebSphere
support sand-boxing drivers within an application, so having multiple
driver versions loaded into a single JEE App Server is not an issue. If
you simply dump the driver into the "global" library, you get all you
deserve IMHO.

As I said, just my personal view on things.

On 26/06/13 23:51, Steven Schlansker wrote:
> On Jun 26, 2013, at 3:29 PM, "Marc G. Fournier" <scrappy@hub.org> wrote:
>
>>> How about, when Kevin's driver is ready:
>>>     • recommending the existing driver for JDBC3 and earlier
>>>     • and Kevin's driver for JDBC4 and greater?
>> Why not just create a 'pre-JDBC4 branch for the current official one and import Kevin's as JDBC4, for going forward?
What I've read seems to indicate a reluctance to make a whole whack of changes on the current code, so putting it over
toa branch shouldn't cause to much angst, should it? 
> Because currently the fork has zero adoption and no momentum, whereas the existing driver has a huge install base of
peoplewho expect to continue to receive updates going forward. 
>
> Not that it couldn't ever be the main branch, but I think you guys are jumping the gun by a lot.  And I'm even a fan
ofdoing the cool new shiny stuff. 
>
> The existing driver is tried and true, and I think for a project of PG-JDBC's stature it's going to take a lot more
thanan alpha driver codebase to switch the project over like that. 
>
>
>
>