Re: unix_socket_directory isn't used by all bin tools - Mailing list pgsql-bugs

From Peter Eisentraut
Subject Re: unix_socket_directory isn't used by all bin tools
Date
Msg-id Pine.LNX.4.30.0103311032090.1120-100000@peter.localdomain
Whole thread Raw
In response to Re: unix_socket_directory isn't used by all bin tools  (Jerome Alet <alet@unice.fr>)
List pgsql-bugs
Jerome Alet writes:

> > The configuration file is only for the server; the clients don't see it.
> > Client tools can use the PGHOST environment variable or the -h option, or
> > whatever else the client has implemented.
>
> I disagree partially, correct me if I'm wrong:
>
> Unix domain sockets are not available accross the network, so in this
> particular case (postmaster not listening on tcp) the client and the
> server are on the same machine, it's mandatory. That's why I think that
> these programs should take care of the server's configuration if it's
> available (and no -h or PGHOST option)

I'm not sure exactly what you disagree with.  The feature "configuration
file" is certainly operating as designed and as documented.  If you want
to propose an additional feature, then you're free to do that, but there
is no way we'll let client programs read the server's configuration file,
they just don't have a business there (if they can find it at all).

If you want to change the location of the local socket file for both
client and server then you can make it a compile-time change.  The primary
reason for it being a run-time option, too, was for "virtual hosting"
setups, and in that case it's doubtful whether a global client-readable
configuration file would even be appropriate.

--
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG: Each UNION | EXCEPT | INTERSECT query must have the same number of columns.
Next
From: pgsql-bugs@postgresql.org
Date:
Subject: segmentation fault in psql