[PATCH] Enable SSL library detection via PQsslAttribute
Jacob Champion <pchampion@vmware.com>
From: Jacob Champion <pchampion@vmware.com>
To: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2022-02-23T18:38:08Z
Lists: pgsql-hackers
Attachments
- 0001-Enable-SSL-library-detection-via-PQsslAttribute.patch (text/x-patch) patch 0001
Hello, As part of the NSS work it came up [1] that clients don't have a good way to ask libpq what SSL library it was compiled with, unless they already have a connection pointer so that they can call PQsslAttribute(conn, "library"). This poses a chicken-and-egg problem: with the NSS proposal, the client may have to know which library is in use before it can construct a proper connection string. For example, I have a test suite that needs to set up an NSS database with certificates before telling libpq to connect using that database. The simplest proposal was to just allow PQsslAttribute() to take NULL as the connection parameter when querying the "library" attribute, and that's what I've done in this patch. In current versions of libpq, the "library" attribute will always be NULL if you pass NULL as the connection; a client that needs to know whether this new behavior is present can look at the LIBPQ_HAS_SSL_LIBRARY_DETECTION feature macro. If this looks good, I'm not sure how best to test it in the regression suite. I see that libpq has an installcheck recipe that compiles a test executable for URI parsing; should I add a simple test alongside that? Thanks, --Jacob [1] https://www.postgresql.org/message-id/a1798e46d6d801344ebc93672c6947ef5297c8a0.camel%40vmware.com
Commits
-
Enable SSL library detection via PQsslAttribute()
- ebc8b7d4416d 15.0 landed