From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Redefine default result from PQhost()? |
Date: | 2015-11-27 10:00:32 |
Message-ID: | CABUevEyz8BvL_ztA8y6t4HDxu8TuN63NGRUW9H8okumNi2++Gg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 26, 2015 at 4:48 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
> > On Wed, Nov 25, 2015 at 11:59 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2015-11-27 10:02:44 | Re: New email address |
Previous Message | Greg Stark | 2015-11-27 09:57:44 | Re: New email address |