Re: Exposing DEFAULT_PGSOCKET_DIR via a libpq function? - Mailing list pgsql-hackers

From Jeremy Drake
Subject Re: Exposing DEFAULT_PGSOCKET_DIR via a libpq function?
Date
Msg-id Pine.LNX.4.64.0603282028460.13056@frousa
Whole thread Raw
In response to Re: Exposing DEFAULT_PGSOCKET_DIR via a libpq function?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, 28 Mar 2006, Tom Lane wrote:

> "Larry Rosenman" <ler@lerctr.org> writes:
> > The other issue is borked installs where the server and libpq disagree.
> > What I'm looking for
> >  is to expose what libpq has for it's default as well as what the server is
> > using.  There is currently
> >  no way to determine what libpq has for it's default.  What happened in the
> > irc case was a partial re-install
> >  with non-matching server and libpq.
>
> [ shrug... ]  So?  There isn't going to be any way that
> random-app-using-libpq is going to have a way to tell the user what the
> underlying copy of libpq is using for this default --- adding a call for
> that will be nothing more nor less than a waste of code space.  You'd be
> best off running strings(1) over the libpq.so file when the question
> comes up.

When I encounter such behavior, my tool of choice tends to be strace(1)
rather than strings(1).  That way, you know what exactly the thing it
wants that it is not finding is...


-- 
Nothing astonishes men so much as common sense and plain dealing.    -- Ralph Waldo Emerson


pgsql-hackers by date:

Previous
From: "Larry Rosenman"
Date:
Subject: Re: Exposing DEFAULT_PGSOCKET_DIR via a libpq function?
Next
From: vidisha.shah@tcs.com
Date:
Subject: Issue in Mapping varchar datatype of Postgre to Oracle