Hi Scot,

I'll look into the first 2 issues. I don't believe many of the state codes come from the comms code, so that's probably not too hard to resolve.

Re: confidence - I can only guess that your apps never used multi-chunk SQL_C_WVARCHAR data, otherwise you surely wouldn't have such confidence in the old driver!!!! :-)

/D
-----Original Message-----
From: "Scot Loach"<sloach@sandvine.com>
Sent: 19/08/05 21:43:22
To: "Dave Page"<dpage@vale-housing.co.uk>, "pgsql-odbc@postgresql.org"<pgsql-odbc@postgresql.org>
Subject: RE: [ODBC] "Official" version

there are some things it doesn't have yet
- proper error handling (the sqlstate return codes are not yet done as far as I can tell)
- disconnect detection using the SQL_ATTR_CONNECTION_DEAD is broken in the libpq version

I don't have confidence that it's as stable as the old driver, since I have found the previous version to be extremely stable over years of use on a large install base, and until I get past at least one of these issues I won't be able to evaluate this version in production. Once I get past these issues I'm pretty sure I'll find some more.

I really do appreciate all the work that has gone into this and I am impressed how quickly it got to this state, I think it's almost there.

scot.


-----Original Message-----
From: pgsql-odbc-owner@postgresql.org
[mailtogsql-odbc-owner@postgresql.org]On Behalf Of Dave Page
Sent: Friday, August 19, 2005 3:41 PM
To: pgsql-odbc@postgresql.org
Subject: [ODBC] "Official" version


I think it's fairly safe to say that the new libpq version of psqlODBC
is more stable than the previous release versions of the driver, and
also now offers more features such as SSL, Kerberos authentication (has
anyone tried this yet?), pgpass files and so on.

In light of this, I think the libpq version should now take over as the
official driver, and lose the 'libpq' suffix that was added for testing.

If anyone has any strong objections, please shriek soon!!

Regards, Dave.

---------------------------(end of broadcast)---------------------------
TIP 1: 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



-----Unmodified Original Message-----
there are some things it doesn't have yet
- proper error handling (the sqlstate return codes are not yet done as far as I can tell)
- disconnect detection using the SQL_ATTR_CONNECTION_DEAD is broken in the libpq version

I don't have confidence that it's as stable as the old driver, since I have found the previous version to be extremely stable over years of use on a large install base, and until I get past at least one of these issues I won't be able to evaluate this version in production. Once I get past these issues I'm pretty sure I'll find some more.

I really do appreciate all the work that has gone into this and I am impressed how quickly it got to this state, I think it's almost there.

scot.


-----Original Message-----
From: pgsql-odbc-owner@postgresql.org
[mailtogsql-odbc-owner@postgresql.org]On Behalf Of Dave Page
Sent: Friday, August 19, 2005 3:41 PM
To: pgsql-odbc@postgresql.org
Subject: [ODBC] "Official" version


I think it's fairly safe to say that the new libpq version of psqlODBC
is more stable than the previous release versions of the driver, and
also now offers more features such as SSL, Kerberos authentication (has
anyone tried this yet?), pgpass files and so on.

In light of this, I think the libpq version should now take over as the
official driver, and lose the 'libpq' suffix that was added for testing.

If anyone has any strong objections, please shriek soon!!

Regards, Dave.

---------------------------(end of broadcast)---------------------------
TIP 1: 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

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match