Re: [INTERFACES] iodbc interface on Unix

I'm sure Byron will correct me if I'm wrong but here's my understanding
of things.

Thomas G. Lockhart wrote:
> OK, I've got some cleaned-up code now. The only outstanding issue I can
> recall is whether CommLog and Debug should absolutely not be allowed in
> the user-accessible .odbc.ini file. btw, I've now realized that the
> driver information is not in the database-specific area as I might have
> claimed earlier, but in another area ([Default]) of the .odbc.ini file.

I believe this an ODBC thing, if you don't give a specific DSN to use
than
iODBC and I think even Windows ODBC manager will use the [Default]
section
to determine which driver library to load.

>
> I suspect that differences in behavior between the Unix iODBC driver and
> the drivers you work with on Windows boxes have lead to some of our
> confusion over where things should go. In fact, it appears that the
> iODBC driver manager does not know about an odbcinst.ini file of any
> sort, so the .odbc.ini file is the only one which is very useful under
> Unix.

Windows ODBC manager shouldn't know about odbcinst.ini either.
odbcinst.ini
is loaded only by psqlodbc as far as I know. None of the settings in
odbcinst.ini
apply to iODBC anyway. Specifically the settings in odbcinst.ini get
read once only
when the driver's dynamic library is first loaded. See file psqlodbc.c
for the dynamic
loading routines that get run. On Linux when a dll is loaded if the
dynamic library
exports a routine _init than it will be run before the call to dlopen(by
iODBC) returns.
_init calls getGlobalDefaults which is the routine that loads everything
from odbcinst.ini.
As far as I know this gets done once only regardless of how many
references to the driver library are currently being held. Obviously
this has consequences on a "real" multiuser system since only the first
person actually causing the driver to be loaded will make the
odbcinst.ini file get read.

>
> So, the CommLog/Debug question seems to have only one answer for Unix
> installations (they must be allowed somewhere in odbc.ini) but we could
> disable that for non-Unix builds. Or, replace references to odbcinst.ini
> with odbc.ini for Unix installations.

If you want true user level control over these settings then the only
solution is to have them read in by data source section. Otherwise, the
settings from the first user's odbcinst.ini file will get used for every
subsequent concurrent loading of the driver. In other words, your second
solution above won't work.

Your other question about what truely belongs in odbcinst.ini is
probably more illuminating here. I would think that Debug should stay in
odbcinst.ini as this is really a driver thing meant only for
"developers". The CommLog setting should probably be moved to the
odbc.ini file and used per datasource. This raises another problem
though in that all CommLog messages are sent to the same psqlodbc.log
file. This isn't good in a multi-user system as the file is opened
read-write only for people in the same user/group which, on RedHat at
least, defaults to a single person. After scanning the qlog source(see
misc.c), I remember now why I didn't bother doing anything about this
before. This will require a non-trivial "fix" since qlog stores the
logging file pointer in a static variable. Since logging was just gravy
to me at the time I didn't worry about it.

Hope this helps.
--
Gerald Gryschuk(ggryschuk(at)scf(dot)sk(dot)ca)
Programmer Analyst
Saskatoon Cancer Centre
((306)655-2746)