Re: setQueryTimeout problem !?!?!

I wonder how "systematically" backward-compatibility and compliance
issues are (can be) dealt with in the driver. Just firing off a blind
shot: what about
1. drawing a base-line for non-compliant features by picking a driver
version released some suitable point in the past with which current
and future driver versions should be backward compatible and create a
list of non-compliant features of that baseline version;
2. introducing a driver option (a configuration property) for each
feature that has a compliant version to turn on the compliant
behavior;
3. having an "umbrella option" for turning on full currently possible
compliance?

Does this make sense? Or is a policy along similar lines already
implemented in the driver?

Thanks
Peter

On Tue, Mar 18, 2008 at 3:25 PM, Dave Cramer <pg@fastcrypt.com> wrote:
>
>
>  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
>
>
>
>  --
>  Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
>  To make changes to your subscription:
>  http://www.postgresql.org/mailpref/pgsql-jdbc
>