Tom Lane wrote:
> "Larry Rosenman" <ler@lerctr.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.
The particular case was psql not being able to connect to a running
postmaster on
the unix socket, because of the mismatch.
What's the harm of a (pseudo code):
const char *PQgetunixsocketdir(void)
{
return(DEFAULT_PGSOCKET_DIR)
}
In libpq, and a psql command line switch to call it.
>
> 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.
This would help as well.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 512-248-2683 E-Mail: ler@lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3683 US
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
