Re: [HACKERS] Re: unixODBC again :-(

[Peter Eisentraut]

Bruce Momjian writes:

  1. Add options to use unixODBC in the configure.in file, the mainly consists of 
finding the root of the unixODBC install prefix, and adding
  -I /unixODBC/path/include and -L /unixODBC/path/lib to the driver build

--with-includes, --with-libraries

  2. Change the way the driver gets config info, to be the same as when built under 
windows. link with -lodbcinst and it provides
  SQLGetPrivateProfileString. the code that calls this works as long as the correct 
define is set.

I don't understand this.  The driver gets the config info just fine; why
add another way?

  3. Stop calling ODBC functions in the driver, this is simple but messy, the 
problem being the call (say) in SQLAllocStmt that calls
  SQLAllocHandle in the driver, ends up calling the SQLAllocHandle in the driver 
manager.

This is fixed using magic linker options on ELF platforms.  I don't recall
how the patch tried to address this, but a better solution is probably
necessary.

  There are a couple of other changes I have made, that you may want
 to add, I added the code to allow encrypted passwords (taken from the
 pg  lib), as crypt is avaiable on unix.

Why not.

 Add the option to detect a
 server name of localhost, and open the unix domain socket,

I don't think so.  localhost is a valid host name.

 in fact try
 two  places, to handle the debian build where the location is
 different.

We have a general approach to non-standard socket names now.

-- 
Peter Eisentraut  [EMAIL PROTECTED]   http://yi.org/peter-e/

Re: [HACKERS] Re: unixODBC again :-(

[Peter Eisentraut]

Nick Gorham writes:

 Well because the driver does not know where to get the config info
 from,

Then the driver should be fixed to do that, with or without unixODBC.

 libodbcinst.so in unixODBC provides SQLGetPrivateProfileString,
 the location of user and system ini files are defined by this lib, if
 it doesn't do this you may have the situation where the driver manager
 gets information from one ini file and the driver from a different
 one.

--with-odbcinst=DIRECTORY

   Add the option to detect a
   server name of localhost, and open the unix domain socket,
 
  I don't think so.  localhost is a valid host name.

 Ok, but don't you think it is worth having some way to get it to use
 UNIX domain sockets instead of TCP ones, for instance if postmaster
 isn't started with a -i ?

Yes, that would be okay, but it's not okay to eliminate a feature to add
another one.

  We have a general approach to non-standard socket names now.

 Great, thats a non problem then, what do you do ?

Pick up DEFAULT_PGSOCKET_DIR from config.h.

-- 
Peter Eisentraut  [EMAIL PROTECTED]   http://yi.org/peter-e/

Re: [HACKERS] Re: unixODBC again :-(

[Bruce Momjian]

Glad these items are being resolved.  THis has sat around too long. 
Please keep discussing and come up with a good patch.  We will help
however we can.


 [EMAIL PROTECTED] wrote:
 
  Nick Gorham writes:
 
   Well because the driver does not know where to get the config info
   from,
 
  Then the driver should be fixed to do that, with or without unixODBC.
 
 Well yes, but again, using the Windows situation as a model (not that
 I would normally suggest windows as a role model for anything), its not the
 drivers job to know or care where the info comes from, that the job of the
 (a) driver manager.
 
   libodbcinst.so in unixODBC provides SQLGetPrivateProfileString,
   the location of user and system ini files are defined by this lib, if
   it doesn't do this you may have the situation where the driver manager
   gets information from one ini file and the driver from a different
   one.
 
  --with-odbcinst=DIRECTORY
 
 Yes but there are two places, the user ~/.odbc.ini directory, and the
 system /sysconfdir/odbc.ini.
 
 using the odbcinst lib, means all drivers can use the same info store, and
 you can just install a binary driver without having to set any
 configuration.
 
 Add the option to detect a
 server name of localhost, and open the unix domain socket,
   
I don't think so.  localhost is a valid host name.
  
   Ok, but don't you think it is worth having some way to get it to use
   UNIX domain sockets instead of TCP ones, for instance if postmaster
   isn't started with a -i ?
 
  Yes, that would be okay, but it's not okay to eliminate a feature to add
  another one.
 
 I would agree with that, I just did it the way I did as it fitted what some
 users needed. Not sure how many people would have a network setup with
 localhost set in dns to point to another machine, Though I agree there is
 no reason why you couldn't do it.
 
We have a general approach to non-standard socket names now.
  
   Great, thats a non problem then, what do you do ?
 
  Pick up DEFAULT_PGSOCKET_DIR from config.h.
 
 Thats ok, but if I was to keep a driver in unixODBC distrib, I would have
 to have a --postgres-socket= option in the config, same problem with
 odbcinst but in reverse. Maybe no simple answer to that one.
 
 All I do at the moment, is have the driver try the two places it knows
 about, maybe it should be in the ini file, perhaps if the socket_location
 is set it would connect via that. It would fix the problem with using
 localhost to switch the connection method.
 
 --
 Nick Gorham
 When I die, I want to go like my grandfather did, gently while sleeping,
 and not like his passangers, screaming in a panic, looking for the
 inflatable raft. -- Seen on ./
 
 
 
 


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