Back-patch to v15, the first version to install these programs. Discussion: https://postgr.es/m/20220501080706.GA1542365@rfd.leadboat.com
The testclient and uri-regress programs in the libpq test suite had quite generic names which didn't convey much meaning. Since they are installed as part of the MSVC test runs, ensure that their purpose is a little bit clearer by renaming with a libpq_ prefix. While at it rename uri-regress to uri_regress to avoid mixing dash and under- score in the same filename. Reported-by: Noah Misch <noah@leadboat.com> Discussion: https://postgr.es/m/20220501080706.GA1542365@rfd.leadboat.com
Currently, libpq client code must have a connection handle before it can query the "library" SSL attribute. This poses problems if the client needs to know what SSL library is in use before constructing a connection string. Allow PQsslAttribute(NULL, "library") to return the library in use -- currently, just "OpenSSL" or NULL. The new behavior is announced with the LIBPQ_HAS_SSL_LIBRARY_DETECTION feature macro, allowing clients to differentiate between a libpq that was compiled without SSL support and a libpq that's just too old to tell. Author: Jacob Champion <pchampion@vmware.com> Reviewed-by: Robert Haas <robertmhaas@gmail.com> Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Discussion: https://postgr.es/m/4c8b76ef434a96627170a31c3acd33cbfd6e41f1.camel@vmware.com
The old form of the test needed a bunch of custom infrastructure. These days tap tests provide the necessary infrastructure to do better. We discussed whether to move this test to src/test/modules, alongside libpq_pipeline, but concluded that the opposite direction would be better. libpq_pipeline will be moved at a later date, once the buildfarm and msvc build infrastructure is ready for it. The invocation of the tap test will be added in the next commit. It involves just enough buildsystem changes to be worth commiting separately. Can't happen the other way round because prove errors out when invoked without tests. Discussion: https://postgr.es/m/20220223203031.ezrd73ohvjgfksow@alap3.anarazel.de
We were being careless in some places about the order of -L switches in link command lines, such that -L switches referring to external directories could come before those referring to directories within the build tree. This made it possible to accidentally link a system-supplied library, for example /usr/lib/libpq.so, in place of the one built in the build tree. Hilarity ensued, the more so the older the system-supplied library is. To fix, break LDFLAGS into two parts, a sub-variable LDFLAGS_INTERNAL and the main LDFLAGS variable, both of which are "recursively expanded" so that they can be incrementally adjusted by different makefiles. Establish a policy that -L switches for directories in the build tree must always be added to LDFLAGS_INTERNAL, while -L switches for external directories must always be added to LDFLAGS. This is sufficient to ensure a safe search order. For simplicity, we typically also put -l switches for the respective libraries into those same variables. (Traditional make usage would have us put -l switches into LIBS, but cleaning that up is a project for another day, as there's no clear need for it.) This turns out to also require separating SHLIB_LINK into two variables, SHLIB_LINK and SHLIB_LINK_INTERNAL, with a similar rule about which switches go into which variable. And likewise for PG_LIBS. Although this change might appear to affect external users of pgxs.mk, I think it doesn't; they shouldn't have any need to touch the _INTERNAL variables. In passing, tweak src/common/Makefile so that the value of CPPFLAGS recorded in pg_config lacks "-DFRONTEND" and the recorded value of LDFLAGS lacks "-L../../../src/common". Both of those things are mistakes, apparently introduced during prior code rearrangements, as old versions of pg_config don't print them. In general we don't want anything that's specific to the src/common subdirectory to appear in those outputs. This is certainly a bug fix, but in view of the lack of field complaints, I'm unsure whether it's worth the risk of back-patching. In any case it seems wise to see what the buildfarm makes of it first. Discussion: https://postgr.es/m/25214.1522604295@sss.pgh.pa.us
It failed to remove a .o file during "make clean", and it lacked a .gitignore file entirely.
This should ease its use on the Windows build environment.
postgres:// URIs are an attempt to "stop the bleeding" in this general area that has been said to occur due to external projects adopting their own syntaxes. The syntaxes supported by this patch: postgres://[user[:pwd]@][unix-socket][:port[/dbname]][?param1=value1&...] postgres://[user[:pwd]@][net-location][:port][/dbname][?param1=value1&...] should be enough to cover most interesting cases without having to resort to "param=value" pairs, but those are provided for the cases that need them regardless. libpq documentation has been shuffled around a bit, to avoid stuffing all the format details into the PQconnectdbParams description, which was already a bit overwhelming. The list of keywords has moved to its own subsection, and the details on the URI format live in another subsection. This includes a simple test program, as requested in discussion, to ensure that interesting corner cases continue to work appropriately in the future. Author: Alexander Shulgin Some tweaking by Álvaro Herrera, Greg Smith, Daniel Farina, Peter Eisentraut Reviewed by Robert Haas, Alexey Klyukin (offlist), Heikki Linnakangas, Marko Kreen, and others Oh, it also supports postgresql:// but that's probably just an accident.