From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Redefine default result from PQhost()? |
Date: | 2015-11-27 18:45:51 |
Message-ID: | 20151127184551.GB5468@gust |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 26, 2015 at 10:48:50AM -0500, Tom Lane 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.
>
> Also, given the precedent of yesterday's psql fix, we should not discount
> the idea that we will be *removing* not adding corner-case bugs in some
> applications. Failure to check for NULL is probably even more common in
> other apps than in psql.
>
> On the other side of the coin, it's worth noting that there is no
> well-defined way for libpq-using apps to discover the value of
> DEFAULT_PGSOCKET_DIR. (psql is getting it by #include'ing an internal
> header file; there is no way to get it from PQconndefaults.) So whatever
> an app might have been doing if it did check for NULL is arguably
> inherently buggy, and bypassing such code will be a good thing.
I agree with each of those points. I see little value in distinguishing
between, in a default build, explicit PGHOST=/tmp and unspecified PGHOST. The
lack of a supported way to discover the default compounds that conclusion.
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2015-11-27 20:29:19 | Re: Potential pointer dereference in plperl.c (caused by transforms patch) |
Previous Message | Tomas Vondra | 2015-11-27 18:01:09 | Re: silent data loss with ext4 / all current versions |