On 06/27/2012 02:50 AM, Robert Jacoby wrote:
> It's a matter of finite resources. If the old driver supported the new db
> then we wouldn't have to redeploy the applications that use it and may be
> able to get away with doing smokes tests after switching the database.
> Redeploying is not trivial and requires quite a bit of coordination. We're
> also not just talking 1 app.
>
> Given that it's not supported, then we would need to do much more
> substantial testing to verify the way we use the old driver would still
> work with the newer database. At that point the amount of testing likely
> dwarfs the cost of redeploying the apps with the newer jar and we might as
> well upgrade.
Yep. In particular, if your app relies on *any* JDBC metadata, either
directly or via an ORM layer or similar, you'll want a driver version
equal to or newer than the database version, because the pg_catalog.*
schema changes somewhat from major version to major version to
accomodate new features, fixes and enhancements. Old drivers won't like
it when a field they expect to be there isn't, a type has changed, etc.
Using an old driver may even expose you to possibly faulty data
access/writes if you use bytea fields, because older drivers don't know
about bytea_format and the new 'hex' default. You'll also have to change
other database settings like standard_conforming_strings .
If you *don't* use JDBC metadata and you can change some settings for
bytea_format, standard_conforming_strings, etc on your updated databases
you might be OK, but I wouldn't particularly recommend it.
--
Craig Ringer
