I think it is important to support backward compatibility in code like 
the JDBC driver.  It is often the case that code opperates in an 
environment where there may be servers at different release levels 
(production databases on 7.0, while dev databases are on 7.1).  Thus I 
think that maintaining backward compatibility to the previous release is 
a minimum requirement.

Begining with the 7.2 JDBC code it is now possible to support backward 
compatibility (i.e. methods now exist to conditionally execute code 
based on server version).  That wasn't the case before now.  In fact the 
7.1 JDBC code is not backward compatible with 7.0 (although the 
incompatibilies are in areas that many users may not notice and thus for 
many it is backwardly compatible).

I am not sure how far back to maintain backward compatibility.  I think 
it is dependent on how often new server versions are released.  In 
general I would not want to force a database user to upgrade more than 
once per year (since doing a dump/restore on a large database can be a 
large hastle).  Therefore I would recommend that going forward the JDBC 
drivers support all back releases that where the latest release within 
the last year.  For example since 7.1 came out in April 2001, this would 
mean supporting 7.0 until April 2002.  And if 7.2 when production in 
October 2001, then 7.1 should be supported until October 2002.

thanks,
--Barry


Tom Lane wrote:
> Barry Lind <[EMAIL PROTECTED]> writes:
> 
>>The multiple statements in one call is there for performance reasons. 
>>Please don't remove it entirely since it works fine in 7.1 and 7.2. 
>>Instead your fix should be conditional based on server version:
>>
> 
> Given that someone else is proposing a patch that will break backward
> compatibility to 7.0 servers anyway, I'm unconvinced that we need this
> at all.  Perhaps a discussion about the costs and benefits of backwards
> compatibility in the JDBC driver is needed --- what tradeoffs do people
> want to make?
> 
>                       regards, tom lane
> 
> 



---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to