Christian Ullrich | 23 Apr 13:37 2015

Bug in execute.c

 From execute.c, SC_setInsertedTable(), line 790:

	if (ptr = strchr(cmd + 1, '.'), NULL != ptr)
		len = ptr - cmd;

This branch is supposed to extract an unquoted schema name from an 
INSERT statement. If that statement is

	INSERT INTO mytable VALUES (1, 1.5)

, the schema name will be "mytable VALUES (1, 1", and the table name, "5)".

I'm sorry I don't have a patch right now. I can come up with one, though.



Sent via pgsql-odbc mailing list (pgsql-odbc <at>
To make changes to your subscription:

Christian Ullrich | 23 Apr 13:23 2015

Problem getting <at> <at> identity

Hello all,

I have a problem with getting  <at>  <at> identity from git master. The result is 
always NULL. I have no idea what the underlying cause is, but the error 
manifests at info.c line 2235:

	col_stmt->internal = TRUE;
	result = PGAPI_ExecDirect(hcol_stmt, (SQLCHAR *) columns_query, 
SQL_NTS, 0);
	if (!SQL_SUCCEEDED(result))
		SC_full_error_copy(stmt, col_stmt, FALSE);
		goto cleanup;

The ExecDirect() call fails with "Connection is already in use."
According to git bisect, the responsible commit is e85fbb "Use libpq for 
everything", but I'm not totally certain because I had to skip a lot.

As for finding the actual problem and fixing it, I'm afraid I won't be 
much help; the innards of this driver are a mystery to me.



Sent via pgsql-odbc mailing list (pgsql-odbc <at>
To make changes to your subscription:

(Continue reading)

Christian Ullrich | 21 Apr 11:22 2015

MSI installers?


is there a reason why there are no current MSI installers on the 
download page? There is a "psqlodbc-setup.exe" in the "msi" directory, 
which I assume contains the x86 and x64 MSIs, so they probably have 
existed at some point.




Sent via pgsql-odbc mailing list (pgsql-odbc <at>
To make changes to your subscription:

Devrim Gündüz | 16 Apr 23:16 2015

[Fwd: [BUGS] BUG #13066: Package postgresql92-odbc has problems]


Got this report in -bugs mailing list. Can someone comment, please?

Regards, Devrim

-------- Forwarded Message --------
> From: rogerwinter <at>
> To: pgsql-bugs <at>
> Subject: [BUGS] BUG #13066: Package postgresql92-odbc has problems
> Date: Thu, 16 Apr 2015 14:56:44 +0000
> The following bug has been logged on the website:
> Bug reference:      13066
> Logged by:          Roger Pitigliani
> Email address:      rogerwinter <at>
> PostgreSQL version: 9.2.0
> Operating system:   CentOS 6 / RHEL 6
> Description:        
> Hi,
> I installed package "postgresql92-odbc-09.03.0400-1PGDG.rhel6.x86_64.rpm" by
> yum, using "pgdg-92" repository.
> Always show the follow message, when try to connect by odbc.
> [S1000][unixODBC]The database does not exist on the server
(Continue reading)


PGSQL ODBC driver crash in CC_get_current_schema


we are using the PostgreSQL 9.2.4 with ODBC driver 09.03.0400.

We experience a driver crash when, for some reason (e.g. insufficient permissions), there is no schema set.

This happens because the strdup in the CC_get_current_schema function in connection.c is executed while the 'select current_schema()' query returned NULL.

We have created a patch to workaround the strdup when the result of QR_get_value_backend_text is NULL:

# diff connection.c.orig connection.c
<                               conn->current_schema = strdup(QR_get_value_backend_text(res, 0, 0));
>                       {
>                               const char* value = QR_get_value_backend_text(res, 0, 0);
>                               if (value == NULL)
>                                       conn->current_schema = NULL;
>                               else
>                                       conn->current_schema = strdup(value);
>                       }

We have tested this patch in our environment and didn't experience any problems. However, we don't oversee the entire code, but expect this not to give any more problems.

Would you be able to include this patch in the next release of the ODBC driver? Feel free to contact in case of any questions.

Met vriendelijke groeten / Kind regards,

Frank van der Aa

Vanboxtel BV

T +31 (0) 492 327 333
F +31 (0) 492 324 326
E fvdaa <at>


PostgreSQL drivers support for Accessing HAWQ Data.



Am trying to access Data located in HAWQ into SAS 9.2 on Solaris 10 environment.

Does these drivers support to get the data from HAWQ into SAS.

Please advice


I have installed the drivers from below link



Thank you


Keith Handlon | 3 Apr 15:39 2015

9.03.0400 windows installer /update option

Is it supposed to work?  It is not listed in the help text window, but is accepted.


I was trying to use the update option to go from the 9.01.0100 to 9.03.0400 driver on a 64 bit windows 7 machine.


It works for the 32 bit driver, but not the 64 bit driver.


The 32-bit update, removes the Program Files (x86)\0901\bin directory, then installs the 9.03.0400 driver in Program Files (x86)\0903\bin.


The 64-bit update, removes the old files from Program Files\0901\bin, then incompletely installs the 09.03.0400 driver in Program Files\0901\bin.




张元超 | 3 Apr 09:28 2015

Failed to compile ODBC by source code

    I got a problem when i compiled ODBC by Microsoft Visual Studio Express 2012 from Windows Desktop,the errors like this:

LINK : warning LNK4199: /DELAYLOAD:libeay32.dll ignored; no imports found from libeay32.dll
LINK : warning LNK4199: /DELAYLOAD:XOLEHLP.DLL ignored; no imports found from XOLEHLP.DLL
setup.obj : error LNK2019: unresolved external symbol _CALL_GetTransactionObject referenced in function _test_connection
setup.obj : error LNK2019: unresolved external symbol _CALL_ReleaseTransactionObject referenced in function _test_connection

Anyone can help me ?Thanks very much.
Vilches, Alejandro | 1 Apr 20:50 2015

odbc vs. libpq performance



I have a simple program that inserts data into a single table (see details below).  When I have the program connect to the DB via ODBC, performance is significantly slower compared to when I have it connect via libpq.  I was able to achieve ~1000 transactions per second using libpq, but only ~4 transactions per second using the ODBC driver.


At first I thought that auto-commit was enabled in ODBC, but I went back and made sure to set auto-commit off and performance remained the same:



So I’m wondering if I’m not setting the auto-commit property correctly, or if I’m doing something wrong with ODBC (perhaps not using the right settings), or if there is an issue in the PostgreSQL ODBC driver.


I searched the archives and found one possibly related issue: <at>  However, I tried the solution they proposed there, but it didn’t improve my issue.


Any help is greatly appreciated!  Thanks!




Important details:

·         About my program

o   Written in C/C++

o   Compiled with GCC 4.4.7

o   The program basically spawns a given number of threads, each one establishes its own connection to the DB and then performs 100 transactions

o   Each transaction simply consists of performing 25 inserts into a single table

o   The program uses prepared statements

o   The program can connect via ODBC or via libpq

o   Both the program and the DB run on the same system, but connect via TCP

·         PostgreSQL version: “PostgreSQL 9.3.6 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11), 64-bit”

·         PostgreSQL installation: followed the YUM installation instructions for Red Hat here:

·         No important changes to postgresql.conf file

·         OS:

o   Red Hat 6.3

o   Linux 2.6.32-279.el6.x86_64 #1 SMP Wed Jun 13 18:24:36 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux

·         Connection:

o   Using unixODBC 2.2.14

o   PostgreSQL ODBC driver: 09.03.0300

o   My DSN configuration:

§  Description = My test DB

§  Driver = <path to PostgreSQL ODBC driver>

§  Trace = No

§  TraceFile =

§  Servername = localhost

§  Database = mytestdb

§  Port = 5432

§  UseServerSidePrepare = 1

§  ReadOnly = No

§  RowVersioning = No

§  ShowSystemTables = No

§  ShowOidColumn = No

§  FakeOidIndex = No

§  ConnSettings =

Jeremiah Penery | 31 Mar 18:06 2015

RPM meta package

I have a package which previously depended on postgresql92-odbc, but I 
would like to be able to upgrade that without explicitly changing the 
dependency, for all future versions.  Maybe something like "depends: 
postgresql-odbc > 9".

The various postgresql-libs RPMs provide this - i.e., I can install 
postgresql94-libs and it satisfies any dependency for postgresql-libs. 
But the only RPM that satisfies the dependency for postgresql-odbc is an 
old one:

> yum provides postgresql-odbc
postgresql-odbc-08.04.0200-1.el6.x86_64 : PostgreSQL ODBC driver
Repo        : base

Is there some reason that postgresqlxx-odbc RPMs don't provide the 
virtual package for postgresql-odbc, so that whatever version I have 
installed will fulfill the dependency?



Sent via pgsql-odbc mailing list (pgsql-odbc <at>
To make changes to your subscription:

Jacobo Vazquez | 27 Mar 12:13 2015

SSPI authentication ASC_REQ_REPLAY_DETECT flag

Hi all,

    I installed PostgreSQL 9.3 on a Windows Server 2012 and I have configured it to use SSPI authentication. The client is on a Windows 7 machine and make the connections via ODBC using a DSN with psqlodbc driver version Authentication works in this scenario for the user authenticated in the client machine. I am always using the same user for connections.

    I used Wireshark in the configuration phase to analyze the traffic between the server and the client. It looks to me that in the authentication phase, the client always sends the same service ticket to postgresql server when a new connection is created, even when I create a new DSN pointing to the same server, it keeps sending the same service ticket.

    Analyzing the source code, in the file src/backend/libpq/auth.c looks like the server is not checking if the service ticket is reused:

    r = AcceptSecurityContext(&sspicred,

    The fourth parameter is not using the ASC_REQ_REPLAY_DETECT flag.

   Am I misunderstanding something or is this the expected behavior? This not means a replay attack risk? I think that if SSL is not used by the connection, a malicious user could capture the authentication package which the client service ticket and then reuse it.

Thanks in advance