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 

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 :-)


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

Reply via email to