Re: Exposing DEFAULT_PGSOCKET_DIR via a libpq function?

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 04:13:18
Message-ID: 8414.1143605598@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:
> That's making the assumption that you know which libpq. I was hoping to
> have a psql commandline
> Switch to dump the info, but with your objection(s), I'll just crawl back
> under my rock.

It's not that I don't feel your pain ... but if you don't know what
version of libpq you're using, I don't see where you get to assume that
psql is invoking the same version as your app-that's-actually-broken.
Seems like there's not any substitute for some forensic effort here.

On the server side, recent discussions about getting pg_ctl to behave
sanely in the face of non-default configurations have been leading me to
think about a proposal like this:

postmaster --show-value guc-variable-name other-switches

with the behavior of parsing the postgresql.conf file, interpreting the
other-switches (which might include -D or -c that'd affect the result)
and then printing the value of the guc-variable to stdout and exiting.
This would allow pg_ctl to deal with issues such as non-default
unix_socket_directory. Doesn't fix your problem of client-side
configuration variation, but would do a bit for the server side.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

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