Re: [HACKERS] ODBC Driver int8 Patch

I am waiting for someone to comment on this. Anyone?

Looks good, but...

We should surround the change with #ifdef ODBC_V2 or ODBC_V3 to mark
what should be changed when moving to the newer standard. No point in
having to remember this from first principles when we do move to V3...

- Thomas

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I am waiting for someone to comment on this. Anyone?

Seems like we need a policy decision: do we want to try to be ODBC v2 or
v3? I don't know what else we might have to change if we want to be
v3-compliant, so that seems like a risky way to proceed right before
a release ...

regards, tom lane

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

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

On Tue, 23 Jan 2001, Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I am waiting for someone to comment on this. Anyone?

Seems like we need a policy decision: do we want to try to be ODBC v2 or
v3? I don't know what else we might have to change if we want to be
v3-compliant, so that seems like a risky way to proceed right before
a release ...

Are we breaking anything by losing the v3-compliancy at this point? The
patch is small, so should be brain-dead to reverse at a later date *if* we
aren't breaking anything by applying it now ...

Applied, with comment about changes need for V3.

On Tue, 23 Jan 2001, Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I am waiting for someone to comment on this. Anyone?

Seems like we need a policy decision: do we want to try to be ODBC v2 or
v3? I don't know what else we might have to change if we want to be
v3-compliant, so that seems like a risky way to proceed right before
a release ...

Are we breaking anything by losing the v3-compliancy at this point? The
patch is small, so should be brain-dead to reverse at a later date *if* we
aren't breaking anything by applying it now ...

-- 
  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?

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

I would like too.

Where can I get the compiled version?
Joseph

----- Original Message -----
From: "Bruce Momjian" <pgman@candle.pha.pa.us>
To: "The Hermit Hacker" <scrappy@hub.org>
Cc: "Tom Lane" <tgl@sss.pgh.pa.us>; "Dave Page" <dpage@vale-housing.co.uk>;
<pgsql-odbc@postgresql.org>; "PostgreSQL-patches"
<pgsql-patches@postgresql.org>
Sent: Tuesday, January 23, 2001 3:24 PM
Subject: [ODBC] Re: [PATCHES] Re: [HACKERS] ODBC Driver int8 Patch

Applied, with comment about changes need for V3.

On Tue, 23 Jan 2001, Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I am waiting for someone to comment on this. Anyone?

Seems like we need a policy decision: do we want to try to be ODBC v2

or

v3? I don't know what else we might have to change if we want to be
v3-compliant, so that seems like a risky way to proceed right before
a release ...

Are we breaking anything by losing the v3-compliancy at this point? The
patch is small, so should be brain-dead to reverse at a later date *if*

we

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: 23 January 2001 17:38
To: Bruce Momjian
Cc: Dave Page; pgsql-odbc@postgresql.org; PostgreSQL-patches
Subject: Re: [PATCHES] Re: [HACKERS] ODBC Driver int8 Patch

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I am waiting for someone to comment on this. Anyone?

Seems like we need a policy decision: do we want to try to be
ODBC v2 or
v3? I don't know what else we might have to change if we want to be
v3-compliant, so that seems like a risky way to proceed right before
a release ...

What advantages would be gained from going to V3 for end users/developers?
Perhaps more importantly, who would be able to do the work? I know Julie
offered to work on the driver, but other than a message a few weeks ago to
say hello I've heard nothing.

I would vote to stick with v2.5 for now but get things like query length,
max tuple size, outer joins (see my message from yesterday) and anything
else that may cause problems for people sorted out.

Regards,

Dave.

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