pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedRE: RE: [PATCHES] ODBC Patch for OJs/Large Querys & Rows
7+ messages / 4 participants
[nested] [flat]
* RE: RE: [PATCHES] ODBC Patch for OJs/Large Querys & Rows
@ 2001-01-25 10:40 Dave Page <dpage@vale-housing.co.uk>
0 siblings, 1 reply; 7+ messages in thread
From: Dave Page @ 2001-01-25 10:40 UTC (permalink / raw)
To: 'Hiroshi Inoue' <Inoue@tpf.co.jp>; +Cc: Bruce Momjian <pgman@candle.pha.pa.us>; 'pgsql-odbc@postgresql.org' <pgsql-odbc@postgresql.org>
> -----Original Message-----
> From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp]
> Sent: 25 January 2001 10:15
> To: Dave Page
> Cc: Bruce Momjian; 'pgsql-odbc@postgresql.org'
> Subject: Re: [ODBC] RE: [PATCHES] ODBC Patch for OJs/Large
> Querys & Rows
>
> It's not me who would send such queries. For exmaple, intelligent
> DAO/RDO/ADO could see that a long or an oj query is allowed and
> send such queries automatically in some cases though I don't know
> if it would really occur or not.
Yes, that could happen, though in reality I suspect it proably wouldn't as
(in my experience - I may be wrong) those technologies do little more than
putting SELECT * FROM in front of a given table name and generating query
based updates.
I suspect that more problems may be caused for apps like MS Query or Seagate
Crystal Reports which might attempt to use outer joins on an older database
(actually Query just enables/disables the relevant join options). As far as
I can tell, the driver doesn't check the backend version (despite returning
the DBMS version which is currently hardcoded), so we'd either need to add a
7.1 protocol option (not nice as it isn't really a different protocol) or do
a SELECT VERSION() on connect to get the exact version string and figure out
what is/isn't possible from that.
I'll look into it but I'm on the wrong end of the learning curve here!
Regards, Dave.
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: RE: [PATCHES] ODBC Patch for OJs/Large Querys & Rows
@ 2001-01-25 13:47 Bruce Momjian <pgman@candle.pha.pa.us>
parent: Dave Page <dpage@vale-housing.co.uk>
0 siblings, 1 reply; 7+ messages in thread
From: Bruce Momjian @ 2001-01-25 13:47 UTC (permalink / raw)
To: Dave Page <dpage@vale-housing.co.uk>; +Cc: 'Hiroshi Inoue' <Inoue@tpf.co.jp>; 'pgsql-odbc@postgresql.org' <pgsql-odbc@postgresql.org>
> Yes, that could happen, though in reality I suspect it proably wouldn't as
> (in my experience - I may be wrong) those technologies do little more than
> putting SELECT * FROM in front of a given table name and generating query
> based updates.
>
> I suspect that more problems may be caused for apps like MS Query or Seagate
> Crystal Reports which might attempt to use outer joins on an older database
> (actually Query just enables/disables the relevant join options). As far as
> I can tell, the driver doesn't check the backend version (despite returning
> the DBMS version which is currently hardcoded), so we'd either need to add a
> 7.1 protocol option (not nice as it isn't really a different protocol) or do
> a SELECT VERSION() on connect to get the exact version string and figure out
> what is/isn't possible from that.
>
> I'll look into it but I'm on the wrong end of the learning curve here!
We usually are more concerned about old libraries talking to new
servers. New libraries talking to old servers are not needed as much.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
^ permalink raw reply [nested|flat] 7+ messages in thread
* RE: [ODBC] RE: [PATCHES] ODBC Patch for OJs/Large Querys & Rows
@ 2001-01-25 16:28 Hiroshi Inoue <Inoue@tpf.co.jp>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 1 reply; 7+ messages in thread
From: Hiroshi Inoue @ 2001-01-25 16:28 UTC (permalink / raw)
To: Dave Page <dpage@vale-housing.co.uk>; Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: pgsql-interfaces; pgsql-odbc@postgresql.org
> -----Original Message-----
> From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
>
> > Yes, that could happen, though in reality I suspect it proably
> wouldn't as
> > (in my experience - I may be wrong) those technologies do
> little more than
> > putting SELECT * FROM in front of a given table name and
> generating query
> > based updates.
> >
> > I suspect that more problems may be caused for apps like MS
> Query or Seagate
> > Crystal Reports which might attempt to use outer joins on an
> older database
> > (actually Query just enables/disables the relevant join
> options). As far as
> > I can tell, the driver doesn't check the backend version
> (despite returning
> > the DBMS version which is currently hardcoded), so we'd either
> need to add a
> > 7.1 protocol option (not nice as it isn't really a different
> protocol) or do
> > a SELECT VERSION() on connect to get the exact version string
> and figure out
> > what is/isn't possible from that.
> >
> > I'll look into it but I'm on the wrong end of the learning curve here!
>
> We usually are more concerned about old libraries talking to new
> servers. New libraries talking to old servers are not needed as much.
>
I strongly object.
Postgres ODBC driver has supported all the way back to version 6.2(
or 6.0 according to a person's opinion). Why could we easily break the
backward compatibility without any consensus ?
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
^ permalink raw reply [nested|flat] 7+ messages in thread
* RE: [ODBC] RE: [PATCHES] ODBC Patch for OJs/Large Querys & Rows
@ 2001-01-25 16:53 Dave Page <dpage@vale-housing.co.uk>
0 siblings, 1 reply; 7+ messages in thread
From: Dave Page @ 2001-01-25 16:53 UTC (permalink / raw)
To: 'Hiroshi Inoue' <Inoue@tpf.co.jp>; Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: pgsql-interfaces; pgsql-odbc@postgresql.org
> -----Original Message-----
> From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp]
> Sent: 25 January 2001 16:28
> To: Dave Page; Bruce Momjian
> Cc: pgsql-interfaces; pgsql-odbc@postgresql.org
> Subject: RE: [ODBC] RE: [PATCHES] ODBC Patch for OJs/Large
> Querys & Rows
>
>
> > -----Original Message-----
> > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
> >
> > We usually are more concerned about old libraries talking to new
> > servers. New libraries talking to old servers are not
> needed as much.
> >
>
> I strongly object.
> Postgres ODBC driver has supported all the way back to version 6.2(
> or 6.0 according to a person's opinion). Why could we easily break the
> backward compatibility without any consensus ?
OK. Here's another (additional) patch. This gets the PostgreSQL version upon
connection, and then uses it to determine what to return from SQLGetInfo for
SQL_DBMS_VER, SQL_MAX_ROW_SIZE, SQL_MAX_STATEMENT_LEN, SQL_OJ_CAPABILITIES
and SQL_OUTER_JOINS. This makes all my changes backward compatible. It also
increments the revision number to 07.01.0001 and corrects the format of the
version number which I previously mistyped as 7.1.0000 (as per ODBC
requirements).
NB: I've not tested this under *nix, only W2K.
Regards, Dave.
Attachments:
odbc.diff (application/octet-stream, 9.4K) download
diff -cr psqlodbc-orig/connection.c psqlodbc/connection.c
*** psqlodbc-orig/connection.c Wed Oct 25 14:15:49 2000
--- psqlodbc/connection.c Thu Jan 25 15:42:40 2001
***************
*** 699,704 ****
--- 699,705 ----
*/
CC_send_settings(self);
CC_lookup_lo(self); /* a hack to get the oid of our large object oid type */
+ CC_lookup_pg_version(self); /* Get PostgreSQL version for SQLGetInfo use */
CC_clear_error(self); /* clear any initial command errors */
self->status = CONN_CONNECTED;
***************
*** 1360,1365 ****
--- 1361,1422 ----
mylog("Got the large object oid: %d\n", self->lobj_type);
qlog(" [ Large Object oid = %d ]\n", self->lobj_type);
+
+ result = SQLFreeStmt(hstmt, SQL_DROP);
+ }
+
+ /* This function gets the version of PostgreSQL that we're connected to.
+ This is used to return the correct info in SQLGetInfo
+ DJP - 25-1-2001
+ */
+ void
+ CC_lookup_pg_version(ConnectionClass *self)
+ {
+ HSTMT hstmt;
+ StatementClass *stmt;
+ RETCODE result;
+ char *szVersion = "0.0";
+ static char *func = "CC_lookup_pg_version";
+
+ mylog( "%s: entering...\n", func);
+
+ /* This function must use the local odbc API functions since the odbc state
+ has not transitioned to "connected" yet.
+ */
+ result = SQLAllocStmt( self, &hstmt);
+ if((result != SQL_SUCCESS) && (result != SQL_SUCCESS_WITH_INFO)) {
+ return;
+ }
+ stmt = (StatementClass *) hstmt;
+
+ result = SQLExecDirect(hstmt, "select version()", SQL_NTS);
+ if((result != SQL_SUCCESS) && (result != SQL_SUCCESS_WITH_INFO)) {
+ SQLFreeStmt(hstmt, SQL_DROP);
+ return;
+ }
+
+ result = SQLFetch(hstmt);
+ if((result != SQL_SUCCESS) && (result != SQL_SUCCESS_WITH_INFO)) {
+ SQLFreeStmt(hstmt, SQL_DROP);
+ return;
+ }
+
+ result = SQLGetData(hstmt, 1, SQL_C_CHAR, self->pg_version, MAX_INFO_STRING, NULL);
+ if((result != SQL_SUCCESS) && (result != SQL_SUCCESS_WITH_INFO)) {
+ SQLFreeStmt(hstmt, SQL_DROP);
+ return;
+ }
+
+ /* There's proably a nicer way of doing this... */
+ /* Extract the Major and Minor numbers from the string. */
+ /* This assumes the string starts 'Postgresql X.X' */
+ sprintf(szVersion, "%c.%c", self->pg_version[11], self->pg_version[13]);
+ self->pg_version_number = (float) atof(szVersion);
+
+ mylog("Got the PostgreSQL version string: '%s'\n", self->pg_version);
+ mylog("Extracted PostgreSQL version number: '%1.1f'\n", self->pg_version_number);
+ qlog(" [ PostgreSQL version string = '%s' ]\n", self->pg_version);
+ qlog(" [ PostgreSQL version number = '%1.1f' ]\n", self->pg_version_number);
result = SQLFreeStmt(hstmt, SQL_DROP);
}
diff -cr psqlodbc-orig/connection.h psqlodbc/connection.h
*** psqlodbc-orig/connection.h Tue Nov 30 02:44:09 1999
--- psqlodbc/connection.h Thu Jan 25 13:29:02 2001
***************
*** 221,226 ****
--- 221,228 ----
DriverToDataSourceProc DriverToDataSource;
char transact_status; /* Is a transaction is currently in progress */
char errormsg_created; /* has an informative error msg been created? */
+ char pg_version[MAX_INFO_STRING]; /* Version of PostgreSQL we're connected to - DJP 25-1-2001 */
+ float pg_version_number;
};
***************
*** 255,260 ****
--- 257,263 ----
int CC_send_function(ConnectionClass *conn, int fnid, void *result_buf, int *actual_result_len, int result_is_int, LO_ARG *argv, int nargs);
char CC_send_settings(ConnectionClass *self);
void CC_lookup_lo(ConnectionClass *conn);
+ void CC_lookup_pg_version(ConnectionClass *conn);
void CC_log_error(char *func, char *desc, ConnectionClass *self);
diff -cr psqlodbc-orig/info.c psqlodbc/info.c
*** psqlodbc-orig/info.c Thu Jan 25 03:28:27 2001
--- psqlodbc/info.c Thu Jan 25 16:42:10 2001
***************
*** 191,197 ****
break;
case SQL_DBMS_VER: /* ODBC 1.0 */
! p = DBMS_VERSION;
break;
case SQL_DEFAULT_TXN_ISOLATION: /* ODBC 1.0 */
--- 191,201 ----
break;
case SQL_DBMS_VER: /* ODBC 1.0 */
! /* The ODBC spec wants ##.##.#### ...whatever... so prepend the driver */
! /* version number to the dbms version string */
! p = POSTGRESDRIVERVERSION;
! strcat(p, " ");
! strcat(p, conn->pg_version);
break;
case SQL_DEFAULT_TXN_ISOLATION: /* ODBC 1.0 */
***************
*** 337,343 ****
case SQL_MAX_ROW_SIZE: /* ODBC 2.0 */
len = 4;
! value = MAX_ROW_SIZE;
break;
case SQL_MAX_ROW_SIZE_INCLUDES_LONG: /* ODBC 2.0 */
--- 341,351 ----
case SQL_MAX_ROW_SIZE: /* ODBC 2.0 */
len = 4;
! if (conn->pg_version_number >= (float) 7.1) { /* Large Rowa in 7.1+ */
! value = MAX_ROW_SIZE;
! } else { /* Without the Toaster we're limited to the blocksize */
! value = BLCKSZ;
! }
break;
case SQL_MAX_ROW_SIZE_INCLUDES_LONG: /* ODBC 2.0 */
***************
*** 350,356 ****
case SQL_MAX_STATEMENT_LEN: /* ODBC 2.0 */
/* maybe this should be 0? */
len = 4;
! value = MAX_STATEMENT_LEN;
break;
case SQL_MAX_TABLE_NAME_LEN: /* ODBC 1.0 */
--- 358,368 ----
case SQL_MAX_STATEMENT_LEN: /* ODBC 2.0 */
/* maybe this should be 0? */
len = 4;
! if (conn->pg_version_number >= (float) 7.0) { /* Long Queries in 7.0+ */
! value = MAX_STATEMENT_LEN;
! } else { /* Prior to 7.0 we used 2*BLCKSZ */
! value = (2*BLCKSZ);
! }
break;
case SQL_MAX_TABLE_NAME_LEN: /* ODBC 1.0 */
***************
*** 419,431 ****
case SQL_OJ_CAPABILITIES: /* ODBC 2.01 */
len = 4;
! value = (SQL_OJ_LEFT |
! SQL_OJ_RIGHT |
! SQL_OJ_FULL |
! SQL_OJ_NESTED |
! SQL_OJ_NOT_ORDERED |
! SQL_OJ_INNER |
! SQL_OJ_ALL_COMPARISON_OPS);
break;
case SQL_ORDER_BY_COLUMNS_IN_SELECT: /* ODBC 2.0 */
--- 431,447 ----
case SQL_OJ_CAPABILITIES: /* ODBC 2.01 */
len = 4;
! if (conn->pg_version_number >= (float) 7.1) { /* OJs in 7.1+ */
! value = (SQL_OJ_LEFT |
! SQL_OJ_RIGHT |
! SQL_OJ_FULL |
! SQL_OJ_NESTED |
! SQL_OJ_NOT_ORDERED |
! SQL_OJ_INNER |
! SQL_OJ_ALL_COMPARISON_OPS);
! } else { /* OJs not in <7.1 */
! value = 0;
! }
break;
case SQL_ORDER_BY_COLUMNS_IN_SELECT: /* ODBC 2.0 */
***************
*** 433,439 ****
break;
case SQL_OUTER_JOINS: /* ODBC 1.0 */
! p = "Y";
break;
case SQL_OWNER_TERM: /* ODBC 1.0 */
--- 449,459 ----
break;
case SQL_OUTER_JOINS: /* ODBC 1.0 */
! if (conn->pg_version_number >= (float) 7.1) { /* OJs in 7.1+ */
! p = "Y";
! } else { /* OJs not in <7.1 */
! p = "N";
! }
break;
case SQL_OWNER_TERM: /* ODBC 1.0 */
diff -cr psqlodbc-orig/psqlodbc.h psqlodbc/psqlodbc.h
*** psqlodbc-orig/psqlodbc.h Thu Jan 25 03:28:27 2001
--- psqlodbc/psqlodbc.h Thu Jan 25 16:31:55 2001
***************
*** 40,47 ****
#define DRIVERNAME "PostgreSQL ODBC"
#define DBMS_NAME "PostgreSQL"
! #define DBMS_VERSION "7.1.0000 PostgreSQL 7.1"
! #define POSTGRESDRIVERVERSION "7.1.0000"
#ifdef WIN32
#define DRIVER_FILE_NAME "PSQLODBC.DLL"
--- 40,46 ----
#define DRIVERNAME "PostgreSQL ODBC"
#define DBMS_NAME "PostgreSQL"
! #define POSTGRESDRIVERVERSION "07.01.0001"
#ifdef WIN32
#define DRIVER_FILE_NAME "PSQLODBC.DLL"
diff -cr psqlodbc-orig/psqlodbc.rc psqlodbc/psqlodbc.rc
*** psqlodbc-orig/psqlodbc.rc Thu Jan 25 10:12:47 2001
--- psqlodbc/psqlodbc.rc Thu Jan 25 16:43:24 2001
***************
*** 204,211 ****
//
VS_VERSION_INFO VERSIONINFO
! FILEVERSION 7,1,0,0
! PRODUCTVERSION 7,1,0,0
FILEFLAGSMASK 0x3L
#ifdef _DEBUG
FILEFLAGS 0x1L
--- 204,211 ----
//
VS_VERSION_INFO VERSIONINFO
! FILEVERSION 7,1,0,1
! PRODUCTVERSION 7,1,0,1
FILEFLAGSMASK 0x3L
#ifdef _DEBUG
FILEFLAGS 0x1L
***************
*** 223,236 ****
VALUE "Comments", "PostgreSQL ODBC driver\0"
VALUE "CompanyName", "Insight Distribution Systems\0"
VALUE "FileDescription", "PostgreSQL Driver\0"
! VALUE "FileVersion", " 7.1.0000\0"
VALUE "InternalName", "psqlodbc\0"
VALUE "LegalCopyright", "\0"
VALUE "LegalTrademarks", "ODBC(TM) is a trademark of Microsoft Corporation. Microsoft® is a registered trademark of Microsoft Corporation. Windows(TM) is a trademark of Microsoft Corporation.\0"
VALUE "OriginalFilename", "psqlodbc.dll\0"
VALUE "PrivateBuild", "\0"
VALUE "ProductName", "Microsoft Open Database Connectivity\0"
! VALUE "ProductVersion", " 7.1.0000\0"
VALUE "SpecialBuild", "\0"
END
END
--- 223,236 ----
VALUE "Comments", "PostgreSQL ODBC driver\0"
VALUE "CompanyName", "Insight Distribution Systems\0"
VALUE "FileDescription", "PostgreSQL Driver\0"
! VALUE "FileVersion", " 07.01.0001\0"
VALUE "InternalName", "psqlodbc\0"
VALUE "LegalCopyright", "\0"
VALUE "LegalTrademarks", "ODBC(TM) is a trademark of Microsoft Corporation. Microsoft® is a registered trademark of Microsoft Corporation. Windows(TM) is a trademark of Microsoft Corporation.\0"
VALUE "OriginalFilename", "psqlodbc.dll\0"
VALUE "PrivateBuild", "\0"
VALUE "ProductName", "Microsoft Open Database Connectivity\0"
! VALUE "ProductVersion", " 07.01.0001\0"
VALUE "SpecialBuild", "\0"
END
END
* Re: RE: [PATCHES] ODBC Patch for OJs/Large Querys & Rows
@ 2001-01-25 17:13 Adam Lang <aalang@rutgersinsurance.com>
parent: Hiroshi Inoue <Inoue@tpf.co.jp>
0 siblings, 1 reply; 7+ messages in thread
From: Adam Lang @ 2001-01-25 17:13 UTC (permalink / raw)
To: ; +Cc: pgsql-odbc@postgresql.org
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
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: RE: [PATCHES] ODBC Patch for OJs/Large Querys & Rows
@ 2001-01-25 23:45 Hiroshi Inoue <Inoue@tpf.co.jp>
parent: Dave Page <dpage@vale-housing.co.uk>
0 siblings, 0 replies; 7+ messages in thread
From: Hiroshi Inoue @ 2001-01-25 23:45 UTC (permalink / raw)
To: Dave Page <dpage@vale-housing.co.uk>; +Cc: Bruce Momjian <pgman@candle.pha.pa.us>; pgsql-odbc@postgresql.org
Dave Page wrote:
>
[snip]
> > >
> > > We usually are more concerned about old libraries talking to new
> > > servers. New libraries talking to old servers are not
> > needed as much.
> > >
> >
> > I strongly object.
> > Postgres ODBC driver has supported all the way back to version 6.2(
> > or 6.0 according to a person's opinion). Why could we easily break the
> > backward compatibility without any consensus ?
>
> OK. Here's another (additional) patch. This gets the PostgreSQL version upon
> connection, and then uses it to determine what to return from SQLGetInfo for
> SQL_DBMS_VER, SQL_MAX_ROW_SIZE, SQL_MAX_STATEMENT_LEN, SQL_OJ_CAPABILITIES
> and SQL_OUTER_JOINS. This makes all my changes backward compatible. It also
> increments the revision number to 07.01.0001 and corrects the format of the
> version number which I previously mistyped as 7.1.0000 (as per ODBC
> requirements).
>
Thanks.
I may be able to fix a large-object related change
using your pg_version(_number).
> NB: I've not tested this under *nix, only W2K.
>
Unfortunately I know no one who could test both :-).
Regards,
Hiroshi Inoue
^ permalink raw reply [nested|flat] 7+ messages in thread
* Re: [ODBC] Re: RE: [PATCHES] ODBC Patch for OJs/Large Querys & Rows
@ 2001-01-26 01:52 Hiroshi Inoue <Inoue@tpf.co.jp>
parent: Adam Lang <aalang@rutgersinsurance.com>
0 siblings, 0 replies; 7+ messages in thread
From: Hiroshi Inoue @ 2001-01-26 01:52 UTC (permalink / raw)
To: Adam Lang <aalang@rutgersinsurance.com>; +Cc: pgsql-interfaces
Adam Lang wrote:
>
> What exactly do you mean by centralize the version info? Do you mean having
> the ODBC driver version match the Postgres DB version?
>
Yes. IIRC, there was a discussion about the autogeneration of
the version numbers from PostgreSQL source configuration. I
object to the idea.
> 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.
Agreed.
Regards,
Hiroshi Inoue
>
> 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
^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2001-01-26 01:52 UTC | newest]
Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2001-01-25 10:40 RE: RE: [PATCHES] ODBC Patch for OJs/Large Querys & Rows Dave Page <dpage@vale-housing.co.uk>
2001-01-25 13:47 ` Bruce Momjian <pgman@candle.pha.pa.us>
2001-01-25 16:28 ` Hiroshi Inoue <Inoue@tpf.co.jp>
2001-01-25 17:13 ` Adam Lang <aalang@rutgersinsurance.com>
2001-01-26 01:52 ` Hiroshi Inoue <Inoue@tpf.co.jp>
2001-01-25 16:53 RE: [ODBC] RE: [PATCHES] ODBC Patch for OJs/Large Querys & Rows Dave Page <dpage@vale-housing.co.uk>
2001-01-25 23:45 ` Hiroshi Inoue <Inoue@tpf.co.jp>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox