Re: Pre-processing during build

From: dmp <danap(at)ttc-cmc(dot)net>
To: Christopher BROWN <brown(at)reflexe(dot)fr>, PostgreSQL JDBC <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: Pre-processing during build
Date: 2015-06-17 16:14:49
Message-ID: 55819CF9.10205@ttc-cmc.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Dave Cramer 2015-06-17 16:21:52 Help Reviewing PR's
Previous Message Christopher BROWN 2015-06-17 15:41:12 Re: Pre-processing during build