Re: Exposing DEFAULT_PGSOCKET_DIR via a libpq function?

From: Jeremy Drake <pgsql(at)jdrake(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Larry Rosenman <ler(at)lerctr(dot)org>, 'Larry Rosenman' <lrosenman(at)pervasive(dot)com>, 'PostgreSQL Hackers List' <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Exposing DEFAULT_PGSOCKET_DIR via a libpq function?
Date: 2006-03-29 04:43:25
Message-ID: Pine.LNX.4.64.0603282028460.13056@frousa
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 28 Mar 2006, Tom Lane wrote:

> "Larry Rosenman" <ler(at)lerctr(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-03-29 04:47:15 Re: Exposing DEFAULT_PGSOCKET_DIR via a libpq function?
Previous Message Larry Rosenman 2006-03-29 04:18:53 Re: Exposing DEFAULT_PGSOCKET_DIR via a libpq function?