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 <barry@xythos.com> 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
>
>
