Re: Exposing DEFAULT_PGSOCKET_DIR via a libpq function?

From: "Larry Rosenman" <ler(at)lerctr(dot)org>
To: "'Jeremy Drake'" <pgsql(at)jdrake(dot)com>, "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "'PostgreSQL Hackers List'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Exposing DEFAULT_PGSOCKET_DIR via a libpq function?
Date: 2006-03-29 04:47:32
Message-ID: 000001c652eb$eb5905f0$0202fea9@lerctr.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jeremy Drake wrote:
>
> 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...
That assumes that the user has strace(1) installed. Yes, I've run into
systems
that don't have it, and have no idea where the RPM/etc is for it :(.

There is also the differences between Linux (strace), SVR4 (truss), *BSD
(ktrace),
etc, whereas a commandline switch to psql and the one-line function I
proposed would
be standard across at least all the unix-like systems (since I think that
the windows code
doesn't enable HAVE_UNIX_SOCKETS, and therefore even if the library returns
a string, it's
useless.

LER

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 512-248-2683 E-Mail: ler(at)lerctr(dot)org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3683 US

In response to

Browse pgsql-hackers by date

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