Re: [INTERFACES] iodbc interface on Unix

> But I guess if it comes down to making all calls _SQL and using them
> internally, then I guess we have to do it. It's ok with me I suppose.
> I guess the Windows linking process does some magic and figures that
> stuff out, and maybe even provides stubs itself for internally called
> functions?!?

Hi Byron. OK, I seem to have a full-featured ODBC interface running
under Unix. Been able to do table selects and updates, and I understand
how the .odbc.ini files should look. It turns out _none_ of the problems
I've had were with your fundamental code (e.g. all socket handshakes
worked without change!) but instead were due to obscure differences in
our compilation and linking environments.

There are a few things to figure out to reintegrate with your main tree:

1) I have a Makefile which integrates with the Postgres distribution. I
assume that you don't want or need it in your primary distribution,
right? So I'll commit it to the Postgres distribution but you might want
to ignore it...

2) The Unix environment uses dynamic linking from the ODBC driver
manager to the psqlodbc driver. On Unix, calls from within psqlodbc to
other routines which are local to psqlodbc actually get linked back to
the ODBC manager rather than staying local. This is not what is
intended, but the behavior makes sense. The way around this is to have
local names for the routines, and jump through the public names when
calling them externally, and call the internal names directly when
within postodbc. I've found a way to _not_ require this internal jump
when #ifdef UNIX is false. The mechanism I'm using requires a macro
defined:

#ifdef UNIX
#define INTERNAL(f) _##f
#else
#define INTERNAL(f) f
#endif

Can you check that this no-op macro works for you when subroutine names
are inside this INTERNAL() macro? For example, in bind.c, change one of
the internal calls to SQLAllocStmt() from something like
result = SQLAllocStmt( self, &hstmt);
to
result = INTERNAL(SQLAllocStmt)( self, &hstmt);

If your C compiler/preprocessor supports this, then we're OK. The
non-Unix code won't have to carry the overhead of these extra calls...

3) Many, but not all, of the source code files have DOS-specific EOL
characters. I'd like to strip those out of the code which is sitting on
Unix boxes, and have them correct when sitting on your DOS machines too.
Can we transfer files using FTP ascii transfers to fix the EOL problems
in the future? Or is there another way which will get this fixed up?? In
the meantime I will clean up all the files I have, and then can get them
to you via the Postgres web site.

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?

5) I've made the odbc.ini file reader case insensitive and more
resilient to embedded whitespace (e.g. keywords no longer have to start
in the first column). As in the previous item, are there considerations
which would make this a bad idea?

Talk to you soon...

- Tom