At 09:51 12.9.2002 -0700, Barry Lind wrote:
>We have been trying to remain backwardly compatible back to 7.0. But as
>you point out some non-backwardly compatible things have been added. It
>is possible to use outer-joins for 7.1 and greater and not use them for
>7.0 (i.e. if (connection.haveMinimumServerVersion("7.1")) { do join
>stuff } else { do existing logic } ). But before doing that does anyone
>have an opinion on how far back the driver should support server versions?
>
>I would suggest we have a policy of supporting the current and two
>previous versions. Since the current production version is 7.2 that
>means supporting 7.0 and 7.1 in the 7.2 driver, and supporting 7.1 and
>7.2 in the 7.3 driver.
My vote goes for this policy. Otherwise the driver gets bloated with code.
And what about the testing phase, people would need to have several
different database versions available for themselves in order to do full
testing. Usually the best tester is the coder himself :-)
>The problem with this is that we generally don't
>backport fixes to previous releases, so if someone found a bug in the
>7.2 driver and was running on a 7.0 database they wouldn't be able to
>easily get a fix since we would fix it in the 7.3 version which wouldn't
>support 7.0. If we decide on a policy I think it is then a good idea to
>have the driver error when connecting to a database version that isn't
>supported.
How about just giving a warning like "Too old database version, not all
features supported". If basic functionality is still supported (SELECT,
INSERT, DELETE, UPDATE) it's still useful.
This reminds me of the current production version of Microsoft's JDBC
driver for SQL Server 2000. They added the version check into the driver
just before the released version (it was nearly fully functional and still
would be with SQL Server 7.0). Of course they have other reasons to do this.
- Panu
>thanks,
>--Barry
>
>
>Panu Outinen wrote:
> > At 10:00 12.9.2002 -0400, Dave Cramer wrote:
> >
> >> Panu,
> >>
> >> The getIndexInfo uses an outer join which won't be backward compatible?
> >> I did apply the getTables patch and will commit soon, can you modify the
> >> getIndexInfo part?
> >
> >
> > Well, both getTables() and getIndexInfo() part of my patch need the
> > 'outer join' functionality. And e.g. getColumns() uses 'outer join'
> > always in current code!
> >
> > So how far backward compatible does it need to be nowadays ? I mean 7.3
> > version of Postgresql is already coming, isn't 7.1.x enough ?
> >
> > - Panu
> >
...