Re: [PATCH] Enable SSL library detection via PQsslAttribute

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Jacob Champion <pchampion(at)vmware(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Enable SSL library detection via PQsslAttribute
Date: 2022-02-23 19:11:34
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2/23/22 13:38, Jacob Champion wrote:
> 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?

Create a TAP tests that calls a small client?



Andrew Dunstan

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message James Coleman 2022-02-23 19:16:30 Re: Synchronizing slots from primary to standby
Previous Message Justin Pryzby 2022-02-23 18:47:32 Re: CLUSTER on partitioned index