Обсуждение: 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>