Re: [INTERFACES] iodbc interface on Unix

Thomas G. Lockhart wrote:

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

There was already a "Makefile.unx" file in the distribution. Is that the
file (or some part thereof) you are using? To answer your question, 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.

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

Yes, this works. BUT, I don't see the real benefit. OK, so the internal
calls will now have the original behavior for Windows, which for all I know,
might not be as fast as just calling the internal function. Internal calls
aren't that intensive anyway so I don't see any real savings here.

BUT, external calls from the driver manager will now have to go through
this thin wrapper layer (SQLGetData --->_SQLGetData), which is a small
performance loss, especially on a call to say, SQLGetData, which could
possibly be called a million times in a session for big data access.

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.

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

OK. I do transfer files to Postgresql.org using ftp ascii. Just the
postsrc.zip distribution would have dos crap in it.

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

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

This sounds fine.

Byron