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: Fri, 21 Aug 1998 12:44:03 -0400
Message-ID: <35DDA3D3.D39F5846@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>
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
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: <35DDA3D3.D39F5846@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