Re: Pre-processing during build - Mailing list pgsql-jdbc

From dmp
Subject Re: Pre-processing during build
Date
Msg-id 55819CF9.10205@ttc-cmc.net
Whole thread Raw
In response to Re: Pre-processing during build  (Christopher BROWN <brown@reflexe.fr>)
Responses Re: Pre-processing during build  (Stephen Nelson <stephen@eccostudio.com>)
List pgsql-jdbc
Christopher BROWN wrote:
> The idea, for administrators and client developers, is that you wouldn't need to
> change anything, and you wouldn't need to pick a driver version.
>
> The idea being, that instead of their being different versions of the driver
> (for different levels of JDBC compatibility) is that there could be one single
> binary.  For type safety and to avoid creating source files from template
> pre-processing, the binary package could contain one driver implementation for
> each implemented JDBC version, each more recent version extending the previous
> version.  Managing this as a client would obviously be a mess, so my suggestion,
> if this approach seemed like an appropriate solution (I'm not pushing for it
> either, but I don't maintain the project...) is that "org.postgresql.Driver"
> could be reimplemented to delegate to the most recent driver implementation
> without changing client code.
>
> This could be done (in the driver code, not in client code) using an approach
> like this (hope the indentation doesn't disappear when sending the e-mail...):
>
 > ~
 > ~

Thank you for the clarification.
danap

danap wrote:
>     Somehow as someone who manages a generic database access tool I don't like the
>     sounds of this requirement. Why as a client developer should I have to detect
>     the appropriate Java Version then somehow figure out the user's requirement
>     for the Driver class to call in your JDBC? I don't have to do this for any other
>     database so why for PostgreSQL's JDBC.
>
>     It may be of no concern really, but that is going to require me to change
>     the coding in my client for instantiating your Driver class, which is the
>     same for all databases so far, all so that you can change your build process,
>     which does not appear to be broken.
>
>     How about backup and state the one, two, three pros, and cons for initiating
>     the change in the build process again. Then highlight what additional work
>     would be required in the code, etc. to accomplish the new build process. Then
>     the list could input on the proposal. Maybe that has already taken place and
>     I missed it?
>
>     danap.



pgsql-jdbc by date:

Previous
From: Christopher BROWN
Date:
Subject: Re: Pre-processing during build
Next
From: Dave Cramer
Date:
Subject: Help Reviewing PR's