Re: JDBC3 Sugquestion

Ian,

There are three reasons why I think what you are suggesting doesn't work
as well as some other suggestions that have been made.

1) Your proposal essentially creates three distinct copies of the code,
one in each of three cvs branches. This means that when a bug needs to
be fixed, then the same fix needs to be done three times. What is
really desired is a good OO way of encapsulating the common code and
having differences only where necessary.

2) How would the source code under your proposal be bundled? Given
that source code for open source software if very important, how would
the pgsql-src.tar.gz file be produced? It seems difficult to get files
from multiple different branches but with the same names pulled and
built into a common source distribution.

3) How would you suggest branches on these branches be done? For
example now that 7.3 development is opened up, there is a 7.2 branch on
the source to facilitate bugs going into 7.2.x. How would you suggest
these release branches be layered on top of your proposed branches
without causing too much confusion?

thanks,
--Barry

Ian Brandt wrote:
> 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
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>
>