From: Bradley McLean <brad@bradm.net>
Patch against 7,2 submitted for comment.
This seems to work just fine; Now, when our users submit a 2 hour
query with four million row sorts by accident, then cancel it 30 seconds
later, it doesn't bog down the server ...
1) Prepare to separate 4 kinds of Descriptor handles.
2) Detect the transaction status more naturally.
3) Improve Parse Statement functionality for the use
of updatable cursors.
4) Improve updatable cursors.
5) Implement SQLGetDescField() and improve SQLColAttribute().
6) etc.
1) Put back the error message for SQLError().
2) Change Disallow premature to handle the SELECTed
result.
3) Put back the behavior of AUTUCOMMIT mode change.
4) Fix SQLColumns for ODBC3.0.
5) Improve the handling of variable bookmark in ODBC3.0.
6) Enable Recognize Unique Index Button.
1) Handle parameter array.
2) Allow re-use of the connection handle after SQLDisconnect.
3) Reject NULL if no indicator specified.
4) Improve the handling of '_' in table name.
5) Unify internal begin/commit/abort operations.
6) Change SQLTables() to return null not "" for the
table_owner.
7) Fix a bug about parameter handling reported by Benoit Menendez.
8) Add cast in handling ODBC date/time escape sequences.
9) Fix a bug about cache_size handing in declare/fetch mode.
[ODBC3.0 related]
10) Improve the handling of descriptor handles(ODBC3.0).
11) Improve the type handling of some types for ODBC3.0.
[Thanks to Marcelo Aceto for his useful patches]
12) Allow nested ODBC escape.
13) Allow changing autocommit on/off inside the transaction
block.
14) Improve the handling of ODBC scalar functions.
an already installed iODBC or unixODBC driver manager. In particular,
use the include files provided by the driver manager over our own,
and use the odbcinst library of the driver manager rather than gpps.c.
Migrate portability sections common to several files into psqlodbc.h.
SQLxxxx() to PGAPI_xxxx().
2) Handle an escaped date/time format as a parameter.
3) Improve the tuple allocation a little.
4) The preparation of ODBC 3.0 a little.
5) Updatable cursors(may be deprecated before long).
1) Tidies up the Datasource Dialogue now the version options are gone.
2) Tidies a comment in info.c.
3) Increments all version numbers to 07.01.0003 to take account of recent
revisions.
Regards, Dave Page
The driver version is 07.01.0002 now.
1) initialized pg_version by DSN's protocol info
so that we could always use pg_version info
once a connection is established (pg_version()
didn't exist before 6.4). PROTOCOL_XX() macros
are removed(except from connection.[ch]).
2) provided a few macros to encapsulate connection's
version info and replaced existent comparison
stuff by those macros.
3) change SQLTables() so that 7.1 servers could show
views.
In addtion, the following patch from Dave Page is applied.
This patch fixes a bug in SQLGetInfo for SQL_DBMS_VER which corrupted the
driver version string. The driver version number has also been incremented
to 07.01.0002.
Regards, Dave. <<odbc.diff>>
dialogue from '6.4/6.5' to '6.5+' and removes some C++ comments from
resource.h (which VC++ insists on putting there).
odbc2.diff adds code to query the PostgreSQL version upon connection. This
is then used to determine what values to return for from SQLGetInfo for
SQL_DBMS_VER, SQL_MAX_ROW_SIZE, SQL_MAX_STATEMENT_LEN, SQL_OJ_CAPABILITIES
and SQL_OUTER_JOINS. The version string as returned by SELECT vERSION() (as
a char array) and the major.minor version number (as a flost) have been
added to the ConnectionClass structure.
Dave Page
problems with char array sizes having set a couple of constants to 0 for
unlimited query length and row length. This additional patch cleans those
problems up by defining a new constant (STD_STATEMENT_LEN) to 65536 and
using that in place of MAX_STATEMENT_LEN.
Another constant (MAX_MESSAGE_LEN) was defined as 2*BLCKSZ, but is now
65536. This is used to define the length of the message buffer in a number
of places and as I understand it (probably not that well!) therefore also
places a limit on the query length. Fixing this properly is beyond my
capabilities but 65536 should hopefully be large enough for most people.
Apologies for being over-enthusiastic and posting 3 patches in one day
rather than 1 better tested one!
Regards,
Dave Page
