>
>
>I mean how does your code decide if this or that functionality is
>available or not ? You can only make sure about that by trying out each
>driver version you support for some functionality.
>
Yup. That's what I do.
>
>For example if you have written code which tests for postgres driver and
>does not check the version of that driver, then after this change your
>runtime code will not work anymore with new postgres drivers, because it
>falsely presumes they support setting a list of integers as a parameter
>using the setObject(x, String, Types.INTEGER) workaround.
>
I know :-(
That's exactly why I was trying so hard to argue against it.
I guess, I am going to have to tell my customers that postgres driver
later than 7.3 is not supported...
or I'll have to modify the new driver to put the original functionality
back, and let them download my version :-(
>
>On the other hand if your code does check version numbers, then indeed
>you have to have some kind of list for each such feature of the drivers
>supporting it, with the versions which support it, and you have to
>follow when they stop doing it, etc. And you have to hard-code this
>information in the application code so it has it at runtime, to be able
>to make those decisions...
>
It is *really really* (I can't repeat it enough times) uncommon for
database vendors (other that postgres obviously - sigh) to make
backwards incompatible changes to their software. In other words, I
don't really need any 'list of versions' - just the earliest supported
version should be enough.
>
>I guess this is a lot of maintenance work...
>
>
It is not really that bad... not until I run into this
backwards-incompatible api changes...
It happened in the past once or twice (before I got here, so I don't
know the details), and they even had to drop support of one of the
databases because of that :-(
Dima
