Re: setQueryTimeout problem !?!?!

On 18-Mar-08, at 9:44 AM, Guillaume Cottenceau wrote:

> 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.

This is bound to be a controversial issue where there is no clear cut
answer. Everyone who has an app that needs it to be silent will
complain that it is now throwing an exception. Everyone who expects it
to honour the spec will complain that it doesn't work. I doubt there
are any drivers in existence which honour *all* of the spec.

That being said, my opinion is that changing it to throw an exception
will be more painful than reverting it and letting people who write
new apps code around it.

Dave