Heikki Linnakangas | 29 Oct 18:55 2014

Let's remove psqlodbc option for geqo

In the spirit of a spring cleanup, I think we should remove the psqlodbc 
configuration option for disabling geqo. I'm sure that's sometimes 
useful, but so are dozens of other backend GUGs. We have a generic 
"connection settings" field in the configuration that you can use if you 
really need to disable qego.

Any objections?

- Heikki


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

Heikki Linnakangas | 29 Oct 17:41 2014

Re: Removing support for < 7.4 servers

On 10/07/2014 10:29 AM, Michael Paquier wrote:
> On Sun, Aug 10, 2014 at 10:18 PM, Michael Paquier <michael.paquier <at> gmail.com
>> wrote:
>> On Mon, Jun 23, 2014 at 2:41 PM, Michael Paquier
>> <michael.paquier <at> gmail.com> wrote:
>>> On Mon, Jun 9, 2014 at 9:59 AM, Michael Paquier <
>> michael.paquier <at> gmail.com>
>>> wrote:
>>>> This work has been rebased on latest master commit (9e71e4d):
>>>> https://github.com/michaelpq/psqlodbc/tree/cleanup-94
> Ping. Code rebase on c685835.

Ok, I think it's time to go ahead with this. Committed the first patch 
in that series, removing support for old protocol versions. Will review 
the rest now.

I don't have the GUI tools to modify the configuration dialogs, so I 
just removed the stuff for KSQO and choosing the protocol. That seems to 
be enough to make it compile, but there's now just gaps in the dialog 
where those options used to be. Will need some re-organizing to make it 
pretty again.

- Heikki


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

blakeduffey . | 28 Oct 21:58 2014

pgsql-odbc and client certs

I'm following steps that have worked in the past, detailed here:

I'm trying this with odbc driver 0903

I receive the error: could not load SSL engine "capi": could not load the shared library

Any assistance appreciated

rohtodeveloper | 20 Oct 13:56 2014

This may be a bug: odbc's function"check_client_encoding" have the same name with postgres's function.

Dear all


I found a problem in the odbc driver on linux platfrom.


Inside the odbc driver,there is a function called check_client_encoding() ,however,there is also a function which has the same name inside the postgres.

once the two functions are in the same process, problems may occur,because the system may choose the wrong function to execute.

If I create a postgres's FUNCTION(myfunc()) using C languageand use this FUNCTION to call the odbc driver(psqlodbcw.so),this problem may happen.


The follow picture explain the situation.

The declaration of the two functions are as follows:       

           UCHAR *check_client_encoding(const UCHAR *sql_string);

           bool check_client_encoding(char **newval, void **extra, GucSource source);



I want to call the odbc's function "check_client_encoding",however it calls the postgres's function "check_client_encoding".

I think this probably is a bug.


Call you help me with this problem?

Thank you so much!




Adrian Klaver | 17 Oct 17:04 2014

Re: PostgreSQL crash at SQLColAttribute()

On 10/17/2014 12:22 AM, Bala krishna Devasani wrote:
> No error message were getting . My application is simply getting crashed
> at function SQLGetInfo().
> i am using linux ubuntu (12.04)
> PostgreSQL:PostgreSQL 9.1
> unixODBC (2.3.2),
> PostgreSQL
> database (9.1),
> psqlodbc driver (3.03) ,
> libodbc++-0.2.3
> Can u please tell me what might be the problem. is it a problem with
> *postgresql odbc driver* (or) *unix odbc driver* ???

Do not have a clue and without more information I doubt it is solvable.


1) What application are using?

2) What are you doing when you use SQLGetInfo()?
     The code that you are using would be helpful.

3) You mentioned something about a trace. Is there information available 
from that trace?

4) If not can you set up a trace?

5) Have you set up logging in ODBC?
    If so what is in the logs?
    If not set it up and then run the code.

> Thanks & Regards
> Balakrishna

Adrian Klaver
adrian.klaver <at> aklaver.com


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

Andreas Buschka | 17 Oct 14:17 2014

Linking tables from MS Access 2013 works fine, but cannot get table and column comments

Hello all,


I am sorry if this question has already been answered, but I could not find it in either the FAQs or by searching this mailing list.


We currently have the following setup:

-   pgsql Server 9.3 running on Windows x64

-   pgODBC driver 9.0.3 on Windows x64 clients (using 32-bit version due to MS Office version)

-   Microsoft Access 2010 (2013 on some workstations) with all patches


We have created some tables and commented them, like this:


COMMENT ON TABLE our_table_name

  IS 'A comment about this table.';

COMMENT ON COLUMN our_table_name.pk_our_table IS 'A comment about the primary key column.';


This works fine, I can see the comments in pgAdmin. However, when I link these tables into a new Microsoft Access database (created a DSN in the 32-bit ODBC admin using default settings), the table and its fields are linked correctly, however, not a single comment, neither for the table nor for any column, is imported into Access. This is rather unfortunate, because our data model is well-documented, and we would like to have this information available in Access as well.


I tried playing with various settings of the ODBC connection, but none of them had any effect on the table link. Is importing the comments possible at all?


All the best,



Oliver Freyd | 17 Oct 12:07 2014

[PATCH] SQLFreeStmt deletes params, but does not reset the stmt->prepared state.


In ResolveOneParam (convert.c:4586) there is code that converts boolean 
'-1' to '1'. This is necessary for MS Access because it uses -1 as true 

In my application, an Access 2013 frontend with a postgresql backend,
sometimes this conversion did not work, and the backend would fail like 

invalid input syntax for type boolean: "-1" at character 399

The statement is like this:

DELETE FROM "public"."someview" WHERE "id" = 13020
AND ... "someboolean" = '-1' ...

This does not happen always, and I've seen it only in DELETE queries,
when I try to delete a row that has a checkbox that is checked (true).
The first try always works, the second try (deleting another row) it fails.

Now this is how it fails (IMHO):

The ResolveOneParam() function relies on the correct types being 
assigned to the parameters, In qb->ipdopts->parameters there is
SQLType and PGType. The SQLType is and enum that does not contain 
boolean, only the PGType can be boolean.

In PGAPI_Execute() (execute.c:1025) it calls prepareParameters, where
the PGTypes are found (don't know how exactly), and put into the stmt,
as stmt->ipd->ipdf.parameters.

If the PGTypes are not 0, the query runs fine. The second time
the query is executed, the query is already prepared (stmt->prepared=5)
and the prepare step is omitted. But then the PGTypes are missing,
the bool '-1' -> '1' conversion is not done and the query fails.

It turns out Access calls SQLFreeStmt(option=SQL_RESET_PARAMS),
that does SC_free_params, so the params get deleted.

But the params contain the result of the prepare call,
so IMHO the stmt->prepared state is now wrong, the transaction is no 
more prepared, so stmt->prepared should be reset to 0.

And that actually fixes the bug.

I hope this is useful, it took quite a while to track this down...

best regards,

	Oliver Freyd

diff --git a/statement.c b/statement.c
index da5abf5..a019d5d 100644
--- a/statement.c
+++ b/statement.c
 <at>  <at>  -581,6 +581,7  <at>  <at>  SC_free_params(StatementClass *self, char option)
  		APD_free_params(SC_get_APDF(self), option);
  		IPD_free_params(SC_get_IPDF(self), option);
+		if (self->prepared!=NOT_YET_PREPARED)\
SC_set_prepared(self, NOT_YET_PREPARED);
  	PDATA_free_params(SC_get_PDTI(self), option);
  	self->data_at_exec = -1;
Attachment (SC_free_params.patch): text/x-diff, 434 bytes


Sent via pgsql-odbc mailing list (pgsql-odbc <at> postgresql.org)
To make changes to your subscription:
Bala krishna Devasani | 15 Oct 17:41 2014

PostgreSQL crash at SQLColAttribute()

Description: i am using postgresql database as a backend,connecting to postgres with unixodbc driver manager and libodbc++ library and psqlodbc driver. when i try to run my application to query some data it is getting crashed. It is getting crashed
at random functions.

i cannot exactly trace which function it is crashing.

it is crashing at three functions like

1.  SQLColAttribute
2.  SQLGetInfo

PostgreSQL version number you are running:

How you installed PostgreSQL:PostgreSQL 9.1 linux ubuntu

Changes made to the settings in the postgresql.conf file: No

Operating system and version:linux ubuntu 12.04 (64-bit)

What program you're using to connect to PostgreSQL:libodbc++-0.2.3 (libodbc++) library

PostgreSQL odbc driver : psqlodbc version(3.03)

ODBC using: unixODBC-2.3.2
For questions about any kind of error:

Description : i am trying to connect  my application to PostgreSQL. while i am trying run select query's it is getting crashed at certain functions.

i am using linux ubuntu (12.04) with unixODBC (2.3.2), PostgreSQL database (9.1), psqlodbc driver (3.03) , libodbc++-0.2.3

Thanks & Regards
Jade Koskela | 13 Oct 23:02 2014

crash bug on closed connection

I have been looking into this crash for a while now, and I finally have a good repro.

After digging through it with wireshark I observed this
client tries to send a query
 retransmit query
 retransmit query
client sends TCP [RST],[ACK]
Now it has crashed, so we restart it again and begin another connection successfully.

It seems that the connection has dropped, but the client was never informed, and it doesn't handle this gracefully. 

I reproed it like this:

On my mac running postgres server:
  Setup port forwarding to emulate a proxy or firewall problem
  ssh -L [public ip]:5433:localhost:5432 -N localhost

On my windows machine:
  Connect to port 5433 on my mac
  Run a query

On my mac:
  Kill the ssh proxy
  sighub postgres
  open the ssh proxy again

On my windows machine:
  Run another query (was never informed that the connection dropped)
  Crash in 

Inoue, Hiroshi | 10 Oct 02:16 2014

Re: Time for a new release?

(2014/10/07 16:48), Inoue, Hiroshi wrote:
> (2014/10/06 21:47), Heikki Linnakangas wrote:
>> There have been a lot of small fixes since the latest release. Time for
>> a new release?
> I have some changes in my local source and would push them in a day or two.

OK I pushed them.

As I mentioned before, I refined a bootstrapper project psqlodbc-setup.
Generated psqlodbc-setup.exe installes both 32bit and 64bit drivers.
Using psqlodbc-setup.exe is a recommended way now.

All drivers, MSIs and psqlodbc-setup.exe are generated by typing

    BuildAll.[ps1|bat] -A

Hiroshi Inoue

>> It would be nice to do a "final" 9.3 release pretty soon, so that we
>> could proceed with Michael Paquier's changes to remove support for < 7.4
>> servers. The plan was to go ahead with that in the first 9.4 release. If
>> we do the last 9.3 release now, we can do the first 9.4 release in a
>> month or so, at roughly the same time the community will likely release
>> server version 9.4.
>> - Heikki

I am using the free version of SPAMfighter.
SPAMfighter has removed 12722 of my spam emails to date.
Get the free SPAMfighter here: http://www.spamfighter.com/len

Do you have a slow PC? Try a Free scan 


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

Cedric Berger | 3 Oct 14:52 2014

ODBC + Access not working for Foreign Table (FDW)


Having just tested my first FDW, I tried to access my foreign
tables with MS Access 2000 using the latest MS ODBC driver.

Unfortunately, I just found that foreign tables are not listed
when you do " Get External Data => Link Tables": Only Views
and Regular tables are shown.

I could workaround the problem by defining a view:

   CREATE VIEW workaround AS SELECT * FROM foreign_table.

But it sucks, and I don't know if there are performance drops
going through a view like that.

I glanced at the ODBC sources, and my guess is that inside
info.c, lines like:

     strcat(tables_query, " where relkind in ('r', 'v')");

should be modified to add the 'f' type.

Is that correct?
Could someone have a look at that?

right now, I can test a MSI, but I've never compiled ODBC myself.