Re: [INTERFACES] iodbc interface on Unix

> > 1) I have a Makefile which integrates with the Postgres
> > distribution.
> ... yes it should be in the distribution. I do include it even
> in the postsrc.zip archive, along with the windows makefile
> psqlodbc.mak. But the psqlodbc.mak
> file is not in the official source whereas the "Makefile.unx" file is.

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.

> > 2) The Unix environment uses dynamic linking from the ODBC driver
> > manager to the psqlodbc driver.
> Yes, this works. BUT, I don't see the real benefit.
> I don't have a problem with these wrappers but the real benefit for
> Windows, would be if the external calls didn't have to go through the
> wrapper layer.
> Therefore, I would rather not have this INTERNAL macro and simply call
> the _SQLxxx functions internally.

Doh! I am pretty sure that there is a linker option on my Linux box
which will make this entire discussion moot. I recalled with clarity
that there _must_ be that option (probably "-Bsymbolic" on my machine)
very soon after carefully converting all of the code to this
internal/external dual interface :(

Will run some tests, but it probably is a non-issue. btw, I'd be willing
to bet that the Windows code never calls back through your wrapper layer
anyway; if it did things would crash just like on my machine :)

> > 3) Many, but not all, of the source code files have DOS-specific EOL
> > characters.
> OK. I do transfer files to Postgresql.org using ftp ascii. Just the
> postsrc.zip distribution would have dos crap in it.

Gerald gave me a suggestion for running unzip. It's a non-issue. Sorry
for the false alarm.

> > 4) I would like to add a couple of keyword parameters to the
> > .odbc.ini configuration file: CommLog and Debug were previously
> > allowed only in the /etc/odbcinit.ini file. Is it OK to add them?
> > Are there considerations which would make this a bad idea?
> I think these log type parameters belong on the driver level as they
> are now, not per datasource. OR did I misunderstand your question?

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.

> > 5) I've made the odbc.ini file reader case insensitive and more
> > resilient to embedded whitespace
> This sounds fine.

OK.

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

I'm leaving town for the weekend, but might be able to do some testing
beforehand. Otherwise, expect some news early next week...

Cheers.

- Tom