Re: Exposing DEFAULT_PGSOCKET_DIR via a libpq function?

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 onthe 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