Hi,
I am interested in JDBC3 support for PostgreSQL. I was going through the
archived posts with regard to this, and have a half suggestion, half
question (hence the new word I just made up in the subject)...
Instead of the previously suggested code forking, build process changing,
and RTTI related ideas, would it be possible to address the problem of
supporting multiple JDBC versions with source control? Here's a rough idea
of how this might work (born out of much ignorance with regard to your
development practices!)...
Create a new CVS repository for JDBC. Take the existing code, extract and
rework everything such as to make a JDBC1 compliant implementation. This
would involve some re-packaging. Everything JDBC related that is currently
under org.postgresql would be moved one level deeper to org.postgresql.jdbc,
except for the stuff currently under org.postgresql.jdbc1, which would be
moved/merged to also be in org.postgresql.jdbc. Once everything is reworked
and checked in, create a jdbc1 branch. Then take the stuff currently in the
org.postgresql.jdbc2 package, and rework that into org.postgresql.jdbc in
this new repository as well, so to have a JDBC2 compliant implementation.
Create a jdbc2 branch.
Updating to JDBC3,4,etc. would then involve updating the existing code to be
compliant, and creating a new branch. The driver would be distributed as
pgjdbc1.jar, pgjdbc2.jar, etc. simply by checking out the corresponding
branch, building under the appropriate jdk, and jar'ing it up. Bug fixes
could be done in the lowest appropriate branch, and merged forward as
appropriate.
As far as users are concerned, having to use the different jar and classpath
based on the JDK/JDBC version they desire to use shouldn't be an issue.
This is very commonplace for such things.
So I hope this idea isn't totally out in left field! Either way I look
forward to JDBC3 support.
Thanks,
Ian