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

From Magnus Hagander
Subject Re: Redefine default result from PQhost()?
Date
Msg-id CABUevEyz8BvL_ztA8y6t4HDxu8TuN63NGRUW9H8okumNi2++Gg@mail.gmail.com
Whole thread Raw
In response to Re: 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 Thu, Nov 26, 2015 at 4:48 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
> On Wed, Nov 25, 2015 at 11:59 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I think we should [ return DEFAULT_PGSOCKET_DIR not NULL ]

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

I don't see why it would need a libpq version bump, as it's not an ABI
breakage.  As for breaking application logic, it's true that any app code
that is explicitly checking for NULL would become dead code, but that
seems pretty harmless.  It's already the case that apps should be prepared
to get back an explicit socket directory path spec; that would merely
become a more common case than before.

Hmm. Good point. I didn't realize they already had to be ready to get a non-default path back.

Of course, the documentation just says it'll return a hostname. It should probably mention that it can return the unix socket path as well - but that's something that's missing already.

-- 

pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: New email address
Next
From: Magnus Hagander
Date:
Subject: Re: New email address