Re: Redefine default result from PQhost()? - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Redefine default result from PQhost()?
Date
Msg-id CABUevEx+eabgYCyS+N1cMiHbg=14FHzhhOaWv30+PrjsP1oysw@mail.gmail.com
Whole thread Raw
In response to Redefine default result from PQhost()?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Redefine default result from PQhost()?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Nov 25, 2015 at 11:59 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Currently, libpq's PQhost() function will return NULL if the connection is
using the default Unix-socket connection address.  This seems like a
pretty dubious definition to me.  psql works around it in several places
with

            host = PQhost(pset.db);
            if (host == NULL)
                host = DEFAULT_PGSOCKET_DIR;

That seems rather duplicative, and it also means that both libpq and psql
have the default socket directory hard-wired into them, which does not
seem like a good thing.  It's conceivable that psql could get used with
a libpq built with a different default, in which case these places would
be outright lying about which socket is being used.

I think we should do this:

 char *
 PQhost(const PGconn *conn)
 {
     if (!conn)
         return NULL;
     if (conn->pghost != NULL && conn->pghost[0] != '\0')
         return conn->pghost;
     else
     {
 #ifdef HAVE_UNIX_SOCKETS
-        return conn->pgunixsocket;
+        if (conn->pgunixsocket != NULL && conn->pgunixsocket[0] != '\0')
+            return conn->pgunixsocket;
+        else
+            return DEFAULT_PGSOCKET_DIR;
 #else
         return DefaultHost;
 #endif
     }
 }

As a definitional change, this would be for HEAD only.

Comments?

I agree with this change in genera. But I wonder if there's a risk here that we break some applications isnt' it? It's clearly a backwards incompatible change, so wouldn't it require a bump of libpq version? And I'm not sure it's worth that on it's own... 

--

pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: pg_stat_replication log positions vs base backups
Next
From: Kouhei Kaigai
Date:
Subject: Re: CustomScan in a larger structure (RE: CustomScan support on readfuncs.c)