| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Larry Rosenman" <ler(at)lerctr(dot)org> |
| Cc: | "'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 03:59:46 |
| Message-ID: | 8269.1143604786@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Larry Rosenman | 2006-03-29 04:02:39 | Re: Exposing DEFAULT_PGSOCKET_DIR via a libpq function? |
| Previous Message | Larry Rosenman | 2006-03-29 03:37:13 | Re: Exposing DEFAULT_PGSOCKET_DIR via a libpq function? |