Re: [INTERFACES] iodbc interface on Unix

Byron will be unavailable for a day or so.

Thomas G. Lockhart wrote:

> > > I'm not proposing to get rid of
> > > Makefile.unx, just to put "Makefile" into the Postgres distribution.
> > I assume this Makefile is not intended to be used to compile for the
> > Windows environment, yes? I just wanted to be clear on it.
>
> Yes, the makefile called "Makefile" is very Postgres-tree-specific. Not
> intended to replace Makefile.unx or other ways of building a driver
> library.
>
> > > Unfortunately, it takes root privilege for
> > > anyone to write into /etc, whereas it takes no system privilege to
> > > do anything else with Postgres. Anyway, shouldn't we have some
> > > driver-level parameters somewhere in ~/.odbc.ini?
> > Would it be possible to
> > have a local "odbcinst.ini" file in the user's home directory which
> > would get read first, and if that didn't exist, go to the
> > /etc/odbcinst.ini file? That way the user could override certain
> > parameters, such as debugging.
>
> OK, I'm not clear on the usage of odbc.ini. My odbc.ini looks like (note
> that this includes my local mods for "Debug" and "CommLog"):
>
> [ODBC Data Sources]
> PostgreSQL = PostgreSQL Driver
> Postgres = Postgres Simple Spec
> PostgresODBC = PostgresODBC
> Default = Postgres Stripped
>
> [PostgreSQL]
> Debug = 1
> CommLog = 1
> ReadOnly = 0
> Driver = /opt/postgres/current/lib/libpsqlodbc.so
> Servername = localhost
> Username = tgl
> Password = "no$way"
> Port = 5432
> Database = test
>
> <snip>
>
> So, each database entry specifies the full information for each
> database, including which driver to use, host info and account info.
> What is the distinction between all of those entries and the "Debug" and
> "CommLog" fields? What _should_ odbcinit.ini be providing which should
> never be in odbc.ini?
>
> > > 6) gcc doesn't like the "mylog" routine being disabled by defining
> > > an empty macro for it.
> > One solution would be to put #ifdef MY_LOG around each of the mylog
> > statements. Another, which I think is easier and probably more
> > beneficial, is to just forget about trying to not compile them in and
> > simply use the Debug parameter to control the printing (which you have
> > to do anyway).
> > So, all you have to do is just always #define MY_LOG and let the
> > "Debug" parameter control it. On windows, I can still use my comment
> > trick.
>
> OK.
>
> So, I just finished removing the stubs and internal calls which I had
> added in (having now found the linker options which make sure things
> resolve within the library), when I found some additional stubs which
> are in results.c. They have been there since before I touched the code.
> Are they required for Windows? If so, why aren't the other routines
> required to be stubbed as they were on my Unix box without the right
> linker options??
>
> - Tom