[unixODBC-dev] Segfault when utilizing libodbc with Asterisk

Nick Gorham nick at lurcher.org
Sat May 19 11:10:49 BST 2007

Peter Harvey wrote:

>>> My recommendation is to use the postgresql-odbc package; that 
>>> version of
>>> psqlodbc is a whole lot newer than the one included in unixODBC.  I've
>>> actually considered stripping the included psql (and mysql) drivers 
>>> from
>>> the Red Hat unixODBC package entirely.  I've been meaning to ask what
>>> the long-term plan is for the included drivers --- since development on
>>> those seems to be separate now, what is the reason for still including
>>> them in the unixODBC distribution?
>> History, nothing else. Its a useful test, but thats about it.
>> If people want I have no objection to removing them. I did talk to 
>> Peter some time ago about splitting stuff up abit anyway.
> As I recall, the drivers were included with unixODBC because;
> 1) the drivers needed to be modified to work with unixODBC (presumably 
> because they were not up-to-spec at the time)
> 2) to make it easier for people to adopt an ODBC solution (one-stop 
> shopping kinda thing)
> 3) to allow a build of the driver (in the case of postgresql) without 
> having to mess with an entire server distro
> 4) some other reasons I am forgetting :)
> IMHO - the mysql and postgresql drivers should be removed from 
> unixODBC and possibly some other stuff

Yep, as I remember Peter, when you started the ini stuff, the only 
postgres driver that mades used of the standard interface 
(SQLGetPrivateProfile etc) was the windows version of the postgres 
driver, so that was what you used. Now driver writers expect to find a 
driver manager and allow their drivers to include the libodbcinst 
functions its not needed.

Ok, I suggest I remove the drivers, postgres, mysql. I would think also 
the text and sqp drivers could be removed as well, but they are useful 
as sample drivers. I wonder whats the best thing to do. Maybe have them 
as a seperate package. What about things like DataManager* and odbctest. 
I would prefer to leave them in as they are useful tools (IMHO).


More information about the unixODBC-dev mailing list