Re: [INTERFACES] iodbc interface on Unix
От | Thomas G. Lockhart |
---|---|
Тема | Re: [INTERFACES] iodbc interface on Unix |
Дата | |
Msg-id | 35DD97AF.30F23F27@alumni.caltech.edu обсуждение исходный текст |
Ответ на | iodbc interface on Unix ("Thomas G. Lockhart" <lockhart@alumni.caltech.edu>) |
Список | pgsql-interfaces |
> 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
В списке pgsql-interfaces по дате отправления: