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