Thomas G. Lockhart wrote:
> I have another Makefile (called "Makefile" :) which can be integrated
> into the Postgres distribution environment, including being generated
> from "Makefile.in". Makefile.unx is not Postgres-tree-specific, and is
> probably a better example for someone trying the build the distribution
> without being in the Postgres tree. 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.
> Hmm. No, you have a good point. 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? Otherwise, the user
> can't do any debugging or diagnostics on new database definitions.
>
I think I have a good solution to this problem. 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.
> Oh, one other issue:
> 6) gcc doesn't like the "mylog" routine being disabled by defining an
> empty macro for it. That leaves stuff which looks like code in bare
> parenthesis in the code body. Any suggestions from a C weenie on how to
> completely disable the code? The problem is that macros seem to prefer a
> fixed number of parameters, and mylog() has a variable number of
> parameters allowed...
>
Yeah, this old thing. Windows allowed me to be lazy and define a macro
which can comment out the rest of the line using the // C++ style comment!
The reason I didn't want the mylog statements to be compiled in was it took
up alot of space plus sometimes the mylog statements are a little risky in
what they print out (that may not be a real issue anymore).
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.
Byron