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(at)fastcrypt(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc
>