Daniel Homerick | 20 May 19:59 2015

Setting Database Name During Connection

The common way to control which database you connect to is apparently through the DSN, or connection string. However, ODBC also allows the database name (distinct from which host/port) to be specified programmatically, but it appears that this may be unimplemented in psqlODBC.


Calling SQLSetConnectAttr with the SQL_ATTR_CURRENT_CATALOG attribute should allow you to specify which database. My expectation is that doing so should override any value specified in the DSN or connection string.


In practice, the SQLSetConnectAttr call returns SQL_SUCCESS, regardless of what database ("catalog") name you specify, and regardless of whether you call it prior to SQLConnect or after. However, calling SQLGetConnectAttr afterwards reveals that nothing was changed by the Set. Attempting to use the specified database fails, consistent with the current database still being whatever was specified in the DSN.


I downloaded the current snapshot (psqlodbc-355ac88) and grepped around, but did not find any references to SQL_ATTR_CURRENT_CATALOG, nor to 3D000 which is the error code for an "Invalid catalog name", which leads me to think it may just be unimplemented and not a more subtle bug. I did not do a more serious investigation however, so take that with a large grain of salt.


Tested on Windows 7, using the odbc driver "Postgre SQL ANSI(x64)" with PostgreSQL 9.2. Testing using the same code works as expected for SQL Server.




As an aside from the bug report, is it correct that there is NOT a way to change the current database through a SQL command with Postgres (i.e. there is no equivalent to "USE" in SQL Server)?



Alex Dunn | 6 May 21:16 2015

Fwd: psqlodbc: HEAD fails to build with recent clang

Sent this to the wrong mailing list; apologies.

----- Forwarded message from Alex Dunn <dunn.alex <at> gmail.com> -----

> Date: Tue, 5 May 2015 21:07:33 -0700
> From: Alex Dunn <dunn.alex <at> gmail.com>
> To: pgsql-bugs <at> postgresql.org
> Subject: psqlodbc: HEAD fails to build with recent clang
> User-Agent: Mutt/1.5.23 (2014-03-12)
> Beginning (I think) in Mavericks, Clang has begun taking functions and
> defining them as macros; they then conflict with declarations via
> headers.  I think this is what's happening with `strlcat` in the most
> recent psqlodbc, since it builds fine with GCC.
> Here are the build logs with system info (errors start at L15 of 03.make):
> https://gist.github.com/dunn/f6ed7ac29a23aa06ba65#file-03-make-L15
> Clang is: Apple LLVM version 6.1.0 (clang-602.0.49) (based on LLVM 3.6.0svn)
> —Alex Dunn

----- End forwarded message -----


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

Josh Hester | 30 Apr 04:08 2015

purpose of exe?

Hi, can you explain the purpose of the exe wrapper around the two msi files?  Will there be a move away from msi files in the future?





Brent Smith | 29 Apr 15:17 2015

Unknown exceptions possibly originating from psqlodbc



I am a software engineer working for Kepware Technologies. We provide control and monitoring software for automation devices. One of our products is an application that stores device data into a customer’s database. We support various database products, Postgres among them.


I was given your contact information by one of our customers, John Psihos at ProcessLinx.


We have been working on an issue with him for several months now, where we are intermittently receiving an unknown exception when trying to update a record set (an MFC call that ultimately goes to the ODBC driver). We have tested our code, as well as MFC (as much as possible) and have found no issues. The most likely area left seems to be the ODBC driver. We are using version 9.3.400 of the ODBC driver, and PostgreSQL 9.4. Once we receive this unknown exception from the record set, it is unusuable (as if it’s internal state is bad, although I haven’t been able to discover any evidence of this on my side), and generates further unknown exceptions when I try to close or delete it.


My primary question is, do you have any insight into what exceptions you might throw in the case of a record set update? Further, are there any tools, header files, debug versions, logging utilities, etc. that you could provide to help us diagnose this problem?


Any help you could provide in this matter would be appreciated.




Brent Smith

Senior Software Engineer | Kepware Technologies


Email: Brent.Smith <at> kepware.com


Follow Us: Facebook | Twitter | LinkedIn | YouTube



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> postgresql.org)
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> postgresql.org)
To make changes to your subscription:

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> postgresql.org)
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> gmail.com
> To: pgsql-bugs <at> postgresql.org
> 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> gmail.com
> 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
> or user authentication failed. 
> Then, to solve, I installed, one previous version. 
> "postgresql92-odbc-09.02.0100-1PGDG.rhel6.x86_64.rpm"
> It's works fine.
> Att,
> -- 
> Sent via pgsql-bugs mailing list (pgsql-bugs <at> postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs


Principal Systems Engineer  <at>  EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter:  <at> DevrimGunduz ,  <at> DevrimGunduzTR


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> vanboxtel.nl
I www.vanboxtel.nl


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.