On Thu, Nov 26, 2015 at 10:48:50AM -0500, Tom Lane wrote: > Magnus Hagander <mag...@hagander.net> writes: > > On Wed, Nov 25, 2015 at 11:59 PM, Tom Lane <t...@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. > > 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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers