Skip site navigation (1) Skip section navigation (2)

Re: Re: unixODBC again :-(

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Nick Gorham <nick(at)lurcher(dot)org>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgreSQL(dot)org>, <pgsql-odbc(at)postgreSQL(dot)org>
Subject: Re: Re: unixODBC again :-(
Date: 2001-01-24 20:20:51
Message-ID: Pine.LNX.4.30.0101242117000.1469-100000@peter.localdomain (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-odbc
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      peter_e(at)gmx(dot)net       http://yi.org/peter-e/


In response to

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2001-01-24 20:36:15
Subject: RE: FW: Postgresql on win32
Previous:From: Bruce MomjianDate: 2001-01-24 20:06:39
Subject: Re: Open 7.1 items

pgsql-odbc by date

Next:From: Dave PageDate: 2001-01-24 22:35:48
Subject: Additional ODBC patch
Previous:From: Nick GorhamDate: 2001-01-24 18:53:42
Subject: Re: Re: unixODBC again :-(

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group