Thread: Re: [HACKERS] ODBC Driver int8 Patch
Patch applied. Thanks. [ Charset ISO-8859-1 unsupported, converting... ] > Hi Bruce, > > Did you accept this patch in the end or was it rejected? > > Regards, Dave. > > > -----Original Message----- > > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > > Sent: 16 January 2001 16:50 > > To: Dave Page > > Cc: 'pgsql-hackers@postgresql.org' > > Subject: Re: [HACKERS] ODBC Driver int8 Patch > > > > > > As I remember, the problem is that this makes us match the > > ODBC v2 spec, > > but then we would not match the v3 spec. Is that correct? > > > > > > [ Charset ISO-8859-1 unsupported, converting... ] > > > Hi, > > > > > > It was suggested that I post this patch here as no notice > > was taken of it > > > when posted to interfaces! > > > > > > This fixes problems with int8 columns which are reported by > > the driver as > > > SQL_BIGINT rather than SQL_CHAR as per the ODBC v2 spec. > > Specifically, I > > > have had problems with MS ADO - any queries that contain an > > int8 column in > > > the resultset will *always* return an empty recordset. > > > > > > Regards, > > > > > > Dave. > > > > > > *** pgtypes.c.orig Fri Dec 22 09:12:22 2000 > > > --- pgtypes.c Fri Dec 22 09:12:22 2000 > > > *************** > > > *** 217,223 **** > > > case PG_TYPE_XID: > > > case PG_TYPE_INT4: return SQL_INTEGER; > > > > > > ! case PG_TYPE_INT8: return SQL_BIGINT; > > > case PG_TYPE_NUMERIC: return SQL_NUMERIC; > > > > > > case PG_TYPE_FLOAT4: return SQL_REAL; > > > --- 217,223 ---- > > > case PG_TYPE_XID: > > > case PG_TYPE_INT4: return SQL_INTEGER; > > > > > > ! case PG_TYPE_INT8: return SQL_CHAR; > > > case PG_TYPE_NUMERIC: return SQL_NUMERIC; > > > > > > case PG_TYPE_FLOAT4: return SQL_REAL; > > > > > > > > > -- > > 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 > > > -- 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 ? config.log ? config.cache ? config.status ? GNUmakefile ? doc/TODO.detail/ProposedTools.doc ? doc/TODO.detail/RDBATools.xls ? src/Makefile.custom ? src/GNUmakefile ? src/Makefile.global ? src/log ? src/crtags ? src/backend/postgres ? src/backend/catalog/global.description ? src/backend/catalog/global.bki ? src/backend/catalog/template1.bki ? src/backend/catalog/template1.description ? src/backend/port/Makefile ? src/bin/initdb/initdb ? src/bin/initlocation/initlocation ? src/bin/ipcclean/ipcclean ? src/bin/pg_config/pg_config ? src/bin/pg_ctl/pg_ctl ? src/bin/pg_dump/pg_dump ? src/bin/pg_dump/pg_restore ? src/bin/pg_dump/pg_dumpall ? src/bin/pg_id/pg_id ? src/bin/pg_passwd/pg_passwd ? src/bin/pgaccess/pgaccess ? src/bin/pgtclsh/Makefile.tkdefs ? src/bin/pgtclsh/Makefile.tcldefs ? src/bin/pgtclsh/pgtclsh ? src/bin/pgtclsh/pgtksh ? src/bin/psql/psql ? src/bin/scripts/createlang ? src/include/config.h ? src/include/stamp-h ? src/interfaces/ecpg/lib/libecpg.so.3.2.0 ? src/interfaces/ecpg/preproc/ecpg ? src/interfaces/libpgeasy/libpgeasy.so.2.1 ? src/interfaces/libpgtcl/libpgtcl.so.2.1 ? src/interfaces/libpq/libpq.so.2.1 ? src/interfaces/perl5/blib ? src/interfaces/perl5/Makefile ? src/interfaces/perl5/pm_to_blib ? src/interfaces/perl5/Pg.c ? src/interfaces/perl5/Pg.bs ? src/pl/plperl/blib ? src/pl/plperl/Makefile ? src/pl/plperl/pm_to_blib ? src/pl/plperl/SPI.c ? src/pl/plperl/plperl.bs ? src/pl/plpgsql/src/libplpgsql.so.1.0 ? src/pl/tcl/Makefile.tcldefs Index: src/interfaces/odbc/pgtypes.c =================================================================== RCS file: /home/projects/pgsql/cvsroot/pgsql/src/interfaces/odbc/pgtypes.c,v retrieving revision 1.15 diff -c -r1.15 pgtypes.c *** src/interfaces/odbc/pgtypes.c 2000/05/27 03:35:14 1.15 --- src/interfaces/odbc/pgtypes.c 2001/01/23 19:07:09 *************** *** 217,223 **** case PG_TYPE_XID: case PG_TYPE_INT4: return SQL_INTEGER; ! case PG_TYPE_INT8: return SQL_BIGINT; case PG_TYPE_NUMERIC: return SQL_NUMERIC; case PG_TYPE_FLOAT4: return SQL_REAL; --- 217,225 ---- case PG_TYPE_XID: case PG_TYPE_INT4: return SQL_INTEGER; ! /* Change this to SQL_BIGINT for ODBC v3 bjm 2001-01-23 */ ! case PG_TYPE_INT8: return SQL_CHAR; ! case PG_TYPE_NUMERIC: return SQL_NUMERIC; case PG_TYPE_FLOAT4: return SQL_REAL;
didn't Tom have an objection to this, or, at least, a concern about forcing v2 specs? On Tue, 23 Jan 2001, Bruce Momjian wrote: > > Patch applied. Thanks. > > [ Charset ISO-8859-1 unsupported, converting... ] > > Hi Bruce, > > > > Did you accept this patch in the end or was it rejected? > > > > Regards, Dave. > > > > > -----Original Message----- > > > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > > > Sent: 16 January 2001 16:50 > > > To: Dave Page > > > Cc: 'pgsql-hackers@postgresql.org' > > > Subject: Re: [HACKERS] ODBC Driver int8 Patch > > > > > > > > > As I remember, the problem is that this makes us match the > > > ODBC v2 spec, > > > but then we would not match the v3 spec. Is that correct? > > > > > > > > > [ Charset ISO-8859-1 unsupported, converting... ] > > > > Hi, > > > > > > > > It was suggested that I post this patch here as no notice > > > was taken of it > > > > when posted to interfaces! > > > > > > > > This fixes problems with int8 columns which are reported by > > > the driver as > > > > SQL_BIGINT rather than SQL_CHAR as per the ODBC v2 spec. > > > Specifically, I > > > > have had problems with MS ADO - any queries that contain an > > > int8 column in > > > > the resultset will *always* return an empty recordset. > > > > > > > > Regards, > > > > > > > > Dave. > > > > > > > > *** pgtypes.c.orig Fri Dec 22 09:12:22 2000 > > > > --- pgtypes.c Fri Dec 22 09:12:22 2000 > > > > *************** > > > > *** 217,223 **** > > > > case PG_TYPE_XID: > > > > case PG_TYPE_INT4: return SQL_INTEGER; > > > > > > > > ! case PG_TYPE_INT8: return SQL_BIGINT; > > > > case PG_TYPE_NUMERIC: return SQL_NUMERIC; > > > > > > > > case PG_TYPE_FLOAT4: return SQL_REAL; > > > > --- 217,223 ---- > > > > case PG_TYPE_XID: > > > > case PG_TYPE_INT4: return SQL_INTEGER; > > > > > > > > ! case PG_TYPE_INT8: return SQL_CHAR; > > > > case PG_TYPE_NUMERIC: return SQL_NUMERIC; > > > > > > > > case PG_TYPE_FLOAT4: return SQL_REAL; > > > > > > > > > > > > > -- > > > 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 > > > > > > > > -- > 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 > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> > didn't Tom have an objection to this, or, at least, a concern about > forcing v2 specs? He said it looked good, I thought. > > On Tue, 23 Jan 2001, Bruce Momjian wrote: > > > > > Patch applied. Thanks. > > > > [ Charset ISO-8859-1 unsupported, converting... ] > > > Hi Bruce, > > > > > > Did you accept this patch in the end or was it rejected? > > > > > > Regards, Dave. > > > > > > > -----Original Message----- > > > > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > > > > Sent: 16 January 2001 16:50 > > > > To: Dave Page > > > > Cc: 'pgsql-hackers@postgresql.org' > > > > Subject: Re: [HACKERS] ODBC Driver int8 Patch > > > > > > > > > > > > As I remember, the problem is that this makes us match the > > > > ODBC v2 spec, > > > > but then we would not match the v3 spec. Is that correct? > > > > > > > > > > > > [ Charset ISO-8859-1 unsupported, converting... ] > > > > > Hi, > > > > > > > > > > It was suggested that I post this patch here as no notice > > > > was taken of it > > > > > when posted to interfaces! > > > > > > > > > > This fixes problems with int8 columns which are reported by > > > > the driver as > > > > > SQL_BIGINT rather than SQL_CHAR as per the ODBC v2 spec. > > > > Specifically, I > > > > > have had problems with MS ADO - any queries that contain an > > > > int8 column in > > > > > the resultset will *always* return an empty recordset. > > > > > > > > > > Regards, > > > > > > > > > > Dave. > > > > > > > > > > *** pgtypes.c.orig Fri Dec 22 09:12:22 2000 > > > > > --- pgtypes.c Fri Dec 22 09:12:22 2000 > > > > > *************** > > > > > *** 217,223 **** > > > > > case PG_TYPE_XID: > > > > > case PG_TYPE_INT4: return SQL_INTEGER; > > > > > > > > > > ! case PG_TYPE_INT8: return SQL_BIGINT; > > > > > case PG_TYPE_NUMERIC: return SQL_NUMERIC; > > > > > > > > > > case PG_TYPE_FLOAT4: return SQL_REAL; > > > > > --- 217,223 ---- > > > > > case PG_TYPE_XID: > > > > > case PG_TYPE_INT4: return SQL_INTEGER; > > > > > > > > > > ! case PG_TYPE_INT8: return SQL_CHAR; > > > > > case PG_TYPE_NUMERIC: return SQL_NUMERIC; > > > > > > > > > > case PG_TYPE_FLOAT4: return SQL_REAL; > > > > > > > > > > > > > > > > > -- > > > > 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 > > > > > > > > > > > > > -- > > 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 > > > > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy > Systems Administrator @ hub.org > primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org > > -- 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
> > didn't Tom have an objection to this, or, at least, a concern about > forcing v2 specs? Oh, I remember now. Tom Lane was saying that we should vote if we want v2 or v3 specs for ODBC. He said moving to v3 in beta may be a problem, and you said this can be easily backed out, so I applied it. I think we are stuck with v2 anyway. > > On Tue, 23 Jan 2001, Bruce Momjian wrote: > > > > > Patch applied. Thanks. > > > > [ Charset ISO-8859-1 unsupported, converting... ] > > > Hi Bruce, > > > > > > Did you accept this patch in the end or was it rejected? > > > > > > Regards, Dave. > > > > > > > -----Original Message----- > > > > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > > > > Sent: 16 January 2001 16:50 > > > > To: Dave Page > > > > Cc: 'pgsql-hackers@postgresql.org' > > > > Subject: Re: [HACKERS] ODBC Driver int8 Patch > > > > > > > > > > > > As I remember, the problem is that this makes us match the > > > > ODBC v2 spec, > > > > but then we would not match the v3 spec. Is that correct? > > > > > > > > > > > > [ Charset ISO-8859-1 unsupported, converting... ] > > > > > Hi, > > > > > > > > > > It was suggested that I post this patch here as no notice > > > > was taken of it > > > > > when posted to interfaces! > > > > > > > > > > This fixes problems with int8 columns which are reported by > > > > the driver as > > > > > SQL_BIGINT rather than SQL_CHAR as per the ODBC v2 spec. > > > > Specifically, I > > > > > have had problems with MS ADO - any queries that contain an > > > > int8 column in > > > > > the resultset will *always* return an empty recordset. > > > > > > > > > > Regards, > > > > > > > > > > Dave. > > > > > > > > > > *** pgtypes.c.orig Fri Dec 22 09:12:22 2000 > > > > > --- pgtypes.c Fri Dec 22 09:12:22 2000 > > > > > *************** > > > > > *** 217,223 **** > > > > > case PG_TYPE_XID: > > > > > case PG_TYPE_INT4: return SQL_INTEGER; > > > > > > > > > > ! case PG_TYPE_INT8: return SQL_BIGINT; > > > > > case PG_TYPE_NUMERIC: return SQL_NUMERIC; > > > > > > > > > > case PG_TYPE_FLOAT4: return SQL_REAL; > > > > > --- 217,223 ---- > > > > > case PG_TYPE_XID: > > > > > case PG_TYPE_INT4: return SQL_INTEGER; > > > > > > > > > > ! case PG_TYPE_INT8: return SQL_CHAR; > > > > > case PG_TYPE_NUMERIC: return SQL_NUMERIC; > > > > > > > > > > case PG_TYPE_FLOAT4: return SQL_REAL; > > > > > > > > > > > > > > > > > -- > > > > 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 > > > > > > > > > > > > > -- > > 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 > > > > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy > Systems Administrator @ hub.org > primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org > > -- 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
On Tue, 23 Jan 2001, Bruce Momjian wrote: > > > > didn't Tom have an objection to this, or, at least, a concern about > > forcing v2 specs? > > Oh, I remember now. Tom Lane was saying that we should vote if we want > v2 or v3 specs for ODBC. He said moving to v3 in beta may be a problem, > and you said this can be easily backed out, so I applied it. I think we > are stuck with v2 anyway. ummm, I said it could be easily backed out *after* you applied it :) but, as I also said, it looks insignificant enough that it can be changed later, as required ... > > > > > > On Tue, 23 Jan 2001, Bruce Momjian wrote: > > > > > > > > Patch applied. Thanks. > > > > > > [ Charset ISO-8859-1 unsupported, converting... ] > > > > Hi Bruce, > > > > > > > > Did you accept this patch in the end or was it rejected? > > > > > > > > Regards, Dave. > > > > > > > > > -----Original Message----- > > > > > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > > > > > Sent: 16 January 2001 16:50 > > > > > To: Dave Page > > > > > Cc: 'pgsql-hackers@postgresql.org' > > > > > Subject: Re: [HACKERS] ODBC Driver int8 Patch > > > > > > > > > > > > > > > As I remember, the problem is that this makes us match the > > > > > ODBC v2 spec, > > > > > but then we would not match the v3 spec. Is that correct? > > > > > > > > > > > > > > > [ Charset ISO-8859-1 unsupported, converting... ] > > > > > > Hi, > > > > > > > > > > > > It was suggested that I post this patch here as no notice > > > > > was taken of it > > > > > > when posted to interfaces! > > > > > > > > > > > > This fixes problems with int8 columns which are reported by > > > > > the driver as > > > > > > SQL_BIGINT rather than SQL_CHAR as per the ODBC v2 spec. > > > > > Specifically, I > > > > > > have had problems with MS ADO - any queries that contain an > > > > > int8 column in > > > > > > the resultset will *always* return an empty recordset. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Dave. > > > > > > > > > > > > *** pgtypes.c.orig Fri Dec 22 09:12:22 2000 > > > > > > --- pgtypes.c Fri Dec 22 09:12:22 2000 > > > > > > *************** > > > > > > *** 217,223 **** > > > > > > case PG_TYPE_XID: > > > > > > case PG_TYPE_INT4: return SQL_INTEGER; > > > > > > > > > > > > ! case PG_TYPE_INT8: return SQL_BIGINT; > > > > > > case PG_TYPE_NUMERIC: return SQL_NUMERIC; > > > > > > > > > > > > case PG_TYPE_FLOAT4: return SQL_REAL; > > > > > > --- 217,223 ---- > > > > > > case PG_TYPE_XID: > > > > > > case PG_TYPE_INT4: return SQL_INTEGER; > > > > > > > > > > > > ! case PG_TYPE_INT8: return SQL_CHAR; > > > > > > case PG_TYPE_NUMERIC: return SQL_NUMERIC; > > > > > > > > > > > > case PG_TYPE_FLOAT4: return SQL_REAL; > > > > > > > > > > > > > > > > > > > > > -- > > > > > 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 > > > > > > > > > > > > > > > > > > -- > > > 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 > > > > > > > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy > > Systems Administrator @ hub.org > > primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org > > > > > > > -- > 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 > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> didn't Tom have an objection to this, or, at least, a concern about
> forcing v2 specs?
>>
>> Oh, I remember now. Tom Lane was saying that we should vote if we want
>> v2 or v3 specs for ODBC. He said moving to v3 in beta may be a problem,
>> and you said this can be easily backed out, so I applied it. I think we
>> are stuck with v2 anyway.
I agree, we probably need to stick with the v2 spec for now. I just
wanted to see if anyone thought that changing the reported version
number would be a better patch ;-)
regards, tom lane