| 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:32:28 |
| Message-ID: | 7728.1143603148@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:
> Tom Lane wrote:
>> pg_config would seem to be the appropriate place, not libpq nor psql.
> The issue is what psql (and any libpq using program) is going to use to find
> the UNIX socket.
No, the issue is where the server put the socket. libpq is the wrong
place because libpq is not the only thing people use to connect to the
server.
If the DBA sets a non-default unix_socket_directory via postgresql.conf
then you're screwed no matter what: no client-side code can hope to tell
you where it is. The only thing that is useful to inspect is the
server's compile-time default, and pg_config is the right mechanism
to inspect that with.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Larry Rosenman | 2006-03-29 03:37:13 | Re: Exposing DEFAULT_PGSOCKET_DIR via a libpq function? |
| Previous Message | Qingqing Zhou | 2006-03-29 02:59:29 | Re: [GENERAL] PANIC: heap_update_redo: no block |