Re: RE: [PATCHES] ODBC Patch for OJs/Large Querys & Rows - Mailing list pgsql-odbc

From Adam Lang
Subject Re: RE: [PATCHES] ODBC Patch for OJs/Large Querys & Rows
Date
Msg-id 00cd01c086f2$16543980$330a0a0a@6014cwpza006
Whole thread Raw
In response to RE: RE: [PATCHES] ODBC Patch for OJs/Large Querys & Rows  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
List pgsql-odbc
What exactly do you mean by centralize the version info?  Do you mean having
the ODBC driver version match the Postgres DB version?

If so, I do agree in doing that... to a degree.  I say we only match major
versions where there are added features.  As an example, 7.0 has many
feature additions over 6.5.  Once the driver supports all the functionality
of 7.0, it should be moved to version 7.0.  Then, if a patch or something is
added to the ODBC to require it being upped a version, we should use very
minor increments, something like a precision of 4 or 5.  (A patched 7.0
driver would be incremented to 7.0.0.0.1) That way, we know a driver version
as 7.0 supports all functionality from 7.0 servers and back.

Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
http://www.rutgersinsurance.com
----- Original Message -----
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Dave Page" <dpage@vale-housing.co.uk>; "Bruce Momjian"
<pgman@candle.pha.pa.us>
Cc: "pgsql-interfaces" <pgsql-interfaces@postgresql.org>;
<pgsql-odbc@postgresql.org>
Sent: Thursday, January 25, 2001 11:28 AM
Subject: RE: RE: [PATCHES] ODBC Patch for OJs/Large Querys & Rows


<snip>
> I also object to centralize the version info. It is preferable that client
> apps and servers are relatively indepedent as much as possible.
> It seems very natural that client apps and the server have separate
> versioning policies. Do we always have to wait for the all-in-one
> release to get improved client apps ?
>
> Regrads,
> Hiroshi Inoue


pgsql-odbc by date:

Previous
From: Dave Page
Date:
Subject: RE: RE: [PATCHES] ODBC Patch for OJs/Large Querys & Rows
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] Re: unixODBC again :-(