Thread: Using 7.1 driver with 7.3?
I'd like to update my version of Postgresql to 7.3, and I'm wondering if it's possible to continue to use the use the 7.1 version of the JDBC driver. The version of a proprietary library we have licensed does not understand the extra decimal places in Postgresql 7.3 datetime types. (We are currently using it with Postgresql 7.1.) But everything else appears to work fine with the new 7.3 jdbc driver. I've tested our stuff with the old driver and the new database, and it appears to work. My question is: is this a good idea? Is there any obvious reason not to do this? The other option is that I might be able to run the 7.3 driver in backwards compatibility mode. Does anyone have any thoughts on this? Thanks, -Mike -- Mike Bridge <mike@bridgecanada.com>
Mike Bridge <mike@bridgecanada.com> writes:
> The version of a proprietary library we have licensed does not
> understand the extra decimal places in Postgresql 7.3 datetime
> types. (We are currently using it with Postgresql 7.1.) But
> everything else appears to work fine with the new 7.3 jdbc driver.
Why don't you just declare your timestamp columns as timestamp(0),
so that the extra decimal places are suppressed?
> I've tested our stuff with the old driver and the new database, and
> it appears to work. My question is: is this a good idea?
I doubt it. There have been a heck of a lot of bug fixes in the JDBC
driver since 7.1, so even if there aren't any compatibility issues to
worry about (which seems unlikely), it would be much better to use the
up-to-date driver.
regards, tom lane
Mike, I would have to concur with tom here, the driver has gone through extensive reworking since 7.1. On top of that, you are painting yourself into a corner. You would be better to solve your problems now. Future servers will not be compatible with 7.1 drivers Dave On Mon, 2002-12-23 at 14:37, Tom Lane wrote: > Mike Bridge <mike@bridgecanada.com> writes: > > The version of a proprietary library we have licensed does not > > understand the extra decimal places in Postgresql 7.3 datetime > > types. (We are currently using it with Postgresql 7.1.) But > > everything else appears to work fine with the new 7.3 jdbc driver. > > Why don't you just declare your timestamp columns as timestamp(0), > so that the extra decimal places are suppressed? > > > I've tested our stuff with the old driver and the new database, and > > it appears to work. My question is: is this a good idea? > > I doubt it. There have been a heck of a lot of bug fixes in the JDBC > driver since 7.1, so even if there aren't any compatibility issues to > worry about (which seems unlikely), it would be much better to use the > up-to-date driver. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- Dave Cramer <Dave@micro-automation.net>
On Mon, 2002-12-23 at 17:37, Tom Lane wrote:
> Mike Bridge <mike@bridgecanada.com> writes:
> > The version of a proprietary library we have licensed does not
> > understand the extra decimal places in Postgresql 7.3 datetime
> > types. (We are currently using it with Postgresql 7.1.) But
> > everything else appears to work fine with the new 7.3 jdbc driver.
>
> Why don't you just declare your timestamp columns as timestamp(0),
> so that the extra decimal places are suppressed?
Most likely because the DB is already being used in production. I ran
into this problem when upgrading our DB admin upgraded our server from
7.1 to 7.2, without letting us know.
We upgraded the driver to 7.2 and it worked, but I really cursed
whoever thought that changing the default behaviour of a timestamp
column was a good idea.
It's a PITA, but I think your best bet is to make a full ASCII dump of
your DB, replace 'timestamp' with 'timestamp (0)' and recreate it.
Good luck, and let us know of the outcome.
> > I've tested our stuff with the old driver and the new database, and
> > it appears to work. My question is: is this a good idea?
>
> I doubt it. There have been a heck of a lot of bug fixes in the JDBC
> driver since 7.1, so even if there aren't any compatibility issues to
> worry about (which seems unlikely), it would be much better to use the
> up-to-date driver.
>
> regards, tom lane
>
--
[]'s
Daniel Serodio
Mike Bridge wrote: > The version of a proprietary library we have licensed does not > understand the extra decimal places in Postgresql 7.3 datetime > types. (We are currently using it with Postgresql 7.1.) But > everything else appears to work fine with the new 7.3 jdbc driver. Obviously, the ideal thing would be to appeal to whoever made the proprietary driver to make it understand the extra decimal places. Failing that, I think you'd be better off patching the 7.3 driver to suppress them than to use the 7.1 driver. Scott
Thanks to everyone who responded. It sounds like it's better to do this the proper way and wait for a vendor fix rather than try to push ahead and muddle through with a mismatched driver. I did try out the timestamp(0) solution, and that appears to work, although I note that there is a slight format difference (no timezone) when I do a "select now()", which makes me think that there are probably other subtle differences lurking about. Thanks! -Mike On Mon, Dec 23, 2002 at 02:52:31PM -0500, Dave Cramer wrote: > Mike, > > I would have to concur with tom here, the driver has gone through > extensive reworking since 7.1. On top of that, you are painting yourself > into a corner. You would be better to solve your problems now. Future > servers will not be compatible with 7.1 drivers -- Mike Bridge <mike@bridgecanada.com>
Mike, Yes, you need to add "with time zone" to the timestamp declaration Dave On Mon, 2002-12-23 at 20:37, Mike Bridge wrote: > Thanks to everyone who responded. It sounds like it's better > to do this the proper way and wait for a vendor fix rather > than try to push ahead and muddle through with a mismatched > driver. > > I did try out the timestamp(0) solution, and that appears to > work, although I note that there is a slight format difference > (no timezone) when I do a "select now()", which makes me think > that there are probably other subtle differences lurking about. > > Thanks! > > -Mike > > > > > On Mon, Dec 23, 2002 at 02:52:31PM -0500, Dave Cramer wrote: > > Mike, > > > > I would have to concur with tom here, the driver has gone through > > extensive reworking since 7.1. On top of that, you are painting yourself > > into a corner. You would be better to solve your problems now. Future > > servers will not be compatible with 7.1 drivers -- Dave Cramer <Dave@micro-automation.net>