Re: Patch for ODBC driver (look for odbc.ini in more than - Mailing list pgsql-patches

It looks like we already have this capability in 7.2:

/*
 * theIniFileName is searched for in:
 *  $HOME/theIniFileName
 *  theIniFileName
 *  ODBCINSTDIR/ODBCINST_INI
 */
DWORD
GetPrivateProfileString(const char *theSection, /* section name */
                        const char *theKey,     /* search key name */
                        const char *theDefault, /* default value if not
                                                 * found */
                        char *theReturnBuffer,  /* return value stored
                                                 * here */
                        size_t theReturnBufferLength,   /* byte length of return
                                                         * buffer */
                        const char *theIniFileName)     /* pathname of ini file
                                                         * to search */

---------------------------------------------------------------------------

> Since most ODBC drivers and driver managers look for odbc.ini in several
> locations on UNIX systems, it would seem sensible to have the PostgreSQL
> driver do the same thing. (This idea occurred to me after five hours of
> trying to figure out what libpsqlodbc didn't like about my /etc/odbc.ini,
> but that's another story.)
>
> iODBC, for example, does the following:
>
> 1) Checks $ODBCINI
> 2) Checks $HOME/.odbc.ini
> 3) Checks ~/.odbc.ini (where ~ is obtained from struct passwd)
> 4) Checks system-wide odbc.ini (in /etc by default)
>
> This is essentially backwards-compatible with the old behaviour, unless
> $ODBCINI is defined (in which case, arguably, the DBA knows what he's doing
> anyway...). It resembles the Windows approach of allowing both user and
> system data sources.
>
> The attached patch implements this search path in 7.1.3's
> GetPrivateProfileString(). It patches the following files:
>
> configure.in
> src/Makefile.global.in
> src/interfaces/odbc/GNUmakefile
> src/interfaces/odbc/dlg_specific.h
> src/interfaces/odbc/gpps.c
>
> It works for me (GNU/Linux i686). Possible issues include:
>
> - Security. Since this library could (unwisely) be called from a setuid
> binary, this is very important. How sensible is it to incorporate the
> contents of an environment variable directly into the first argument to
> fopen()? All relevant calls to fopen() are read-only (PG_BINARY_R).
>
> - Portability. The new code shouldn't be any less portable than the 7.1.3
> code, but I might have missed something.
>
> - Consistency. Is the configure script option (--with-odbc=DIR) properly
> named? I followed the convention set by --with-odbcinst, but the name I
> chose could conceivably be confused with --enable-odbc. It might be more
> appropriate (albeit less consistent) to call it --with-odbc-ini.
>
> - Should one obtain the current user's home directory from /etc/passwd by
> doing getpwuid(getuid()) or getpwuid(geteuid())? Currently I - like the
> 7.1.3 version of GetPrivateProfileString() - use the former, but it's
> something worth thinking about.
>
> - While I think I understand the somewhat convoluted code I replaced in
> GetPrivateProfileString(), I am occasionally wrong. ;)
>
> Feedback on these and any other issues would be very much appreciated.
>
> Regards,
> Ross Thomas
>

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026