From: Byron Nikolaidis <byronn@insightdist.com>
To: Thomas G. Lockhart <lockhart@alumni.caltech.edu>
Cc: Gerald Gryschuk <ggryschuk@scf.sk.ca>
Cc: Postgres Interfaces Mailing List <pgsql-interfaces@postgreSQL.org>
Subject: Re: [INTERFACES] iodbc interface on Unix
Date: Mon, 24 Aug 1998 10:29:48 -0400
Message-ID: <35E178DC.137ED18@insightdist.com> (raw)
References: <35D99896.DFB21123@alumni.caltech.edu>
<35D9D132.4DE6ACB8@insightdist.com>
<86iujpr0qh.fsf@avd.gcom.ru>
<35DAD65D.34165A2F@insightdist.com>
<35DAE850.93FC000C@alumni.caltech.edu>
<35DB06BB.16F5D38D@alumni.caltech.edu>
<35DB1A0A.53F5BD81@insightdist.com>
<35DB2F55.CF1072DA@scf.sk.ca>
<35DB3107.894B0E3C@insightdist.com>
<35DD97AF.30F23F27@alumni.caltech.edu>
<35DDA3D3.D39F5846@insightdist.com>
<35DE2B1C.8F52CF5E@alumni.caltech.edu>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: byronn@insightdist.com, lockhart@alumni.caltech.edu, ggryschuk@scf.sk.ca
Subject: Re: [INTERFACES] iodbc interface on Unix
In-Reply-To: <35E178DC.137ED18@insightdist.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox