> > 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