Dave Cramer <pg 'at' fastcrypt.com> writes:
>> See previous discussion that prompted this change at http://archives.postgresql.org/pgsql-jdbc/2008-01/msg00088.php
>
> Unfortunately the argument assumes that our users are developing new
> applications, not using the driver in an existing application. I think
> this change should be reversed. A considerable number of people will
> not be in a position to use an old driver with newer servers just to
> avoid this.
That's really a matter of practice - how much do you afford to
break in order to fix previous problems or add features. Here,
the story is to fix an unexpected behaviour of the JDBC driver
(setQueryTimeout silently did nothing; it's *bad* to accept a
query timeout value but then not implement any timeout; a
correctly designed application will legally assume that the
queries will timeout after the configured amount of time, which
is not the case).
Last year, we have upgraded from a 7.4 server to a 8.2 server. I
can tell you that it's quite incorrect to assume that the
application, running fine on 7.4, would magically run fine on 8.2
too - actually, quite a lot of SQL queries were "broken", because
of 8.2 not accepting UPDATE and DELETE FROM with implicit SELECT
on different tables. We've had to validate our application again,
and I think it's normal.
That is to say, when the database is migrated from major
releases, the application (or the DB layer) sometimes needs
slight modifications, and it would be unreasonable deployment
practices to not validate the application again anyway.
--
Guillaume Cottenceau, MNC Mobile News Channel SA, an Alcatel-Lucent Company
Av. de la Gare 10, 1003 Lausanne, Switzerland - direct +41 21 317 50 36
