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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers