I personally am against the idea of having the JDBC driver on a
completely different schedule from the server. I beleive that many
people like the binary distributions of Postgres. And that the binary
distributions should include the jdbc driver. Since the binary
distributions are tied to server release versions there needs to be high
quality releases of the jdbc code that correspond to each server
release. Another reason is that there are often server changes that
cause older versions of the driver not to work with newer versions of
the database (while these should be avoided, they happen). Therefore if
the driver version isn't tied to the server version, there will be some
window where there isn't a JDBC driver that works with the latest server
release.
Now having said that, there isn't any reason that the jdbc code can't be
released more frequently than the server. But without a lot more
developers working on the JDBC code, that isn't going to happen. It is
difficult enough to keep up with the changes in the server with the
current number of jdbc developers. (not that I am complaining about the
rapid advancement of server functionality mind you :-)
thanks,
--Barry
Gunnar Rønning wrote:
> * Bruce Momjian <[EMAIL PROTECTED]> wrote:
> |
> | This issue came up recently in relation to backpatching a python fix,
> | and the conclusion was that jdbc 7.1.X is "a hopeless cause" and I tend
> | to agree. I had >6 unapplied jdbc patches at the time we released 7.1.
> | They are all now in CVS.
>
> I've mentioned it before, but I really think it would nice to decouple the
> release cycles of the core engine from the interfaces. Make them separate
> projects.
>
> Just my kroner,
> Gunnar
>
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
