Thread: Status of ODBC driver managers on Unix
I've been looking at a patch provided by Nick Gorham from the unixODBC
effort to make the PostgreSQL ODBC driver support unixODBC better. All
the while I have been wondering what exactly our ODBC driver does support
on Unix systems now.
It is generally claimed that psqlodbc is supposed to work with the iODBC
driver manager, and it is evident that some source files where in fact
copied over from some ancient version of iODBC. However, iODBC has
changed quite a bit since then so I wonder if it would still work.
The major issues involved with "supporting" one driver manager or another
seem to be:
1. Where to get the include files from, and
2. Where to get the routines to read the .ini file from.
On Windows, the answer to both of these questions is "from the system".
On unixish systems we have the following choices in theory:
a) Write/provide your own
b) Get them from an already installed driver manager of choice.
i) Link in the odbcinst library that the driver manager provides
ii) Don't link in the odbcinst library that the driver manager provides,
instead rely on runtime binding to find the routines in the driver
manager. Not sure if that would work.
We currently support (a), and the unixODBC patch I have pretty much wants
us to support (b)(i). So some questions in my mind are:
* Is (a) really useful and reliable at all?
* Is (b)(ii) an option?
* What sort of options do we want to provide to installers about choosing,
e.g., --with-odbc-driver-manager={unixodbc|iodbc|none}?
* Is it reasonable to attempt to support more than one driver manager in
one installation? (probably not, I'd say)
Comments?
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Peter Eisentraut wrote:
>
> I've been looking at a patch provided by Nick Gorham from the unixODBC
> effort to make the PostgreSQL ODBC driver support unixODBC better. All
> the while I have been wondering what exactly our ODBC driver does support
> on Unix systems now.
>
> It is generally claimed that psqlodbc is supposed to work with the iODBC
> driver manager, and it is evident that some source files where in fact
> copied over from some ancient version of iODBC. However, iODBC has
> changed quite a bit since then so I wonder if it would still work.
>
> The major issues involved with "supporting" one driver manager or another
> seem to be:
>
> 1. Where to get the include files from, and
>
> 2. Where to get the routines to read the .ini file from.
>
> On Windows, the answer to both of these questions is "from the system".
> On unixish systems we have the following choices in theory:
>
> a) Write/provide your own
>
> b) Get them from an already installed driver manager of choice.
>
> i) Link in the odbcinst library that the driver manager provides
>
> ii) Don't link in the odbcinst library that the driver manager provides,
> instead rely on runtime binding to find the routines in the driver
> manager. Not sure if that would work.
>
> We currently support (a), and the unixODBC patch I have pretty much wants
> us to support (b)(i). So some questions in my mind are:
>
> * Is (a) really useful and reliable at all?
>
> * Is (b)(ii) an option?
>
> * What sort of options do we want to provide to installers about choosing,
> e.g., --with-odbc-driver-manager={unixodbc|iodbc|none}?
>
> * Is it reasonable to attempt to support more than one driver manager in
> one installation? (probably not, I'd say)
>
> Comments?
I don't want to maintain our driver on unix by myself
but I don't like the current support style for iODBC.
If we would support unixODBC, we should support (b)(i)
IMHO. gpps.c seems harmful for unixODBC. I don't think
it's preferable for iODBC and unixODBC to have a common
driver. I'd thought the following once before.
Provide subdirectories for compilation e.g. ./iODBC
./unixODBC ./Windows. Each subdirectory would have
its own makefile at least and specific sources like
gpps.c for iDOBC if necessary. Common sources are
still in the current directory but the objects would
be put into the each subdirectories when the compilation
is invoked.
I'm not sure about how to change the current iODBC
support. I didn't find the library in iODBC like
odbcinst in unixODBC. I've not tested if libpsqlodbc.so
itself could be the one. If there are some people
who expect continuous iODBC support, gpps.c should
be removed or improved at least.
regards,
Hiroshi Inoue
Hiroshi Inoue writes: > Provide subdirectories for compilation e.g. ./iODBC > ./unixODBC ./Windows. Each subdirectory would have > its own makefile at least and specific sources like > gpps.c for iDOBC if necessary. Common sources are > still in the current directory but the objects would > be put into the each subdirectories when the compilation > is invoked. Something like that, but where do you install the drivers? E.g., you'd have ./iODBC/libpsqlodbc.so and ./unixODBC/libpsqlodbc.so, but when you install them the names clash again. We should probably encode the meaning of the file in the file name, such as libpsqliodbc.so and libpsqlunixodbc.so. (A separate Windows version is probably not necessary, since you rarely use the same source tree to build both on Unix and on Windows.) This could be easy to arrange with two make targets that link in a different library, but the subject of include files is tricky. I'm not sure if it's reasonable to have both iODBC and unixODBC installed since they both install some of the same files, such as sql.h and sqlext.h. > I'm not sure about how to change the current iODBC > support. I didn't find the library in iODBC like > odbcinst in unixODBC. The version 3.0.5 I'm looking at contains a library libiodbcinst which contains the function SQLGetPrivateProfileString. > If there are some people who expect continuous iODBC support, gpps.c > should be removed or improved at least. Probably removed. But another thing that occurred to me is that if you want to use ODBC on Unix for ApplixWare or StarOffice you don't necessarily have a driver manager installed with header files and such, so we probably need to keep the standalone version. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
> -----Original Message----- > From: Peter Eisentraut [mailto:peter_e@gmx.net] > > Hiroshi Inoue writes: > > > Provide subdirectories for compilation e.g. ./iODBC > > ./unixODBC ./Windows. Each subdirectory would have > > its own makefile at least and specific sources like > > gpps.c for iDOBC if necessary. Common sources are > > still in the current directory but the objects would > > be put into the each subdirectories when the compilation > > is invoked. > > Something like that, but where do you install the drivers? E.g., you'd > have ./iODBC/libpsqlodbc.so and ./unixODBC/libpsqlodbc.so, but when you > install them the names clash again. AFAIK the driver's name of unixODBC is libodbcpsql.so currently and doesn't conflict with libosqlodbc.so. > This could be easy to arrange with two make targets that link in a > different library, but the subject of include files is tricky. I'm not > sure if it's reasonable to have both iODBC and unixODBC installed since > they both install some of the same files, such as sql.h and sqlext.h. > > > I'm not sure about how to change the current iODBC > > support. I didn't find the library in iODBC like > > odbcinst in unixODBC. > > The version 3.0.5 I'm looking at contains a library libiodbcinst which > contains the function SQLGetPrivateProfileString. Hmm we may be able to have a common driver for unixODBC, iODBC(newer) and Merant DM(according to Nick Gorham). Is it possible to provide a dummy libodbcinst and link it at compile time ? If so we don't need the packages at build time though there remains a problem where/how to find sql(ext).h. > > > If there are some people who expect continuous iODBC support, gpps.c > > should be removed or improved at least. > > Probably removed. > > But another thing that occurred to me is that if you want to use ODBC on > Unix for ApplixWare or StarOffice you don't necessarily have a driver > manager installed with header files and such, so we probably need to keep > the standalone version. Agreed. regards, Hiroshi Inoue
Okay, I've implemented and committed the following: --with-iodbc builds driver against iODBC's headers and -liodbcinst --with-unixodbc builds driver against unixODBC's headers and -lodbcinst (neither) what we had before (both) doesn't work (too complicated right now) (The patch looks larger than the change is conceptually because I moved some of the common #ifndef WIN32 code into psqlodbc.h so we don't have to repeat it everywhere.) The --with-iodbc build works cleanly, which is to be expected. The --with-unixodbc build issues a number of warnings about "assignment from incompatible pointer type" and "int format, long int arg", which point out 64-bit cleanness problems (on the part of our driver). Remaining issues: * libpsqlodbc vs. libodbcpsql: I followed this iODBC/unixODBC schism right now, but I'm not sure I like it. * Shared library version: The driver version shipped with unixODBC has a completely different version number than our driver. Does it matter? What should we do? * The code still accesses the global odbcinst.ini file directly by name in some places, rather than relying on the odbcinst library to find it. This should be fixed, but I'm not sure how in each case. Maybe something for Nick to look at. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Hiroshi Inoue writes: > Hmm we may be able to have a common driver for unixODBC, > iODBC(newer) and Merant DM(according to Nick Gorham). > Is it possible to provide a dummy libodbcinst and link it at compile > time ? gpps.c is our dummy libodbcinst. > If so we don't need the packages at build time How would you expect the driver to find SQLGetPrivateProfileString if you don't have the driver manager package installed? -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Nick Gorham writes: > Hmm, what does it need out of odbcinst.ini ? The normal way is a call to > > SQLGetPrivateProfileString(.... "odbcinst.ini" ); Okay, I moved to absolute path references to gpps.c, so the driver manager's search mechanisms should work now. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Peter Eisentraut wrote: > > Hiroshi Inoue writes: > > > Hmm we may be able to have a common driver for unixODBC, > > iODBC(newer) and Merant DM(according to Nick Gorham). > > Is it possible to provide a dummy libodbcinst and link it at compile > > time ? > > gpps.c is our dummy libodbcinst. Oops iODBC has an iodbcsint library not an odbcinst. It seems difficult to have a common library. regards, Hiroshi Inoue
Peter Eisentraut wrote: > > Remaining issues: > > * libpsqlodbc vs. libodbcpsql: I followed this iODBC/unixODBC schism > right now, but I'm not sure I like it. How do we check the build and e.g. connection behavior of the both packages ? regards, Hiroshi Inoue
Peter Eisentraut wrote: > But another thing that occurred to me is that if you want to use ODBC on > Unix for ApplixWare or StarOffice you don't necessarily have a driver > manager installed with header files and such, so we probably need to keep > the standalone version. Well last time I looked ApplixWare shipped with the unixODBC DM libs There is a different way you could do this. the patch I sent made the build use the unixODBC header files in the compile and then link with libodbcinst, thats the clean way IMHO. However, you could continue using the header files that are in the odbc directory, and just add a option to disable the builtin SQLGetPrivateProfile and link in a libodbcinst. the configure option would just need to point to the libodbcinst. -- Nick Gorham Don't worry, be happy
Peter Eisentraut wrote: > Remaining issues: > > * libpsqlodbc vs. libodbcpsql: I followed this iODBC/unixODBC schism > right now, but I'm not sure I like it. me neither, but once there is a clean set of pg driver code, I can either remove the unixodbc version of the driver, or use identical code and give the same name. > * Shared library version: The driver version shipped with unixODBC has a > completely different version number than our driver. Does it matter? > What should we do? Again, maynot be a issue after the merge. > * The code still accesses the global odbcinst.ini file directly by name in > some places, rather than relying on the odbcinst library to find it. > This should be fixed, but I'm not sure how in each case. Maybe > something for Nick to look at. Hmm, what does it need out of odbcinst.ini ? The normal way is a call to SQLGetPrivateProfileString(.... "odbcinst.ini" ); BTW, its worth making sure the name of the ini file in the call to SQLGetPrivateProfileString is in lower case. unixODBC doesn't care, but the Merant DM, which I think is a direct port of the Windows one, doesn't seem to know that files are case sensitive, so will try and open the file with the UC name and fail. Thats the only change I had to make to get our interbase driver working transparently with either libodbcinst -- Nick Gorham Don't worry, be happy