Re: Add ssl_(supported|shared)_groups to sslinfo

From: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
To: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
Subject: Re: Add ssl_(supported|shared)_groups to sslinfo
Date: 2026-09-08 15:12:49
Message-ID: aqAlC4G8bTekShA5@ddolgov-thinkpadt14sgen1.rmtde.csb
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Sun, Sep 06, 2026 at 02:04:01AM -0700, Zsolt Parragi wrote:
> + /*
> + * SSL_group_to_name can return NULL in case of an error, e.g. when no
> + * such name was registered for some reason.
> + */
> + group_name = SSL_group_to_name(ssl, nid);
> + if (group_name == NULL)
> + ereport(ERROR,
> + (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
> + errmsg("unknown OpenSSL group at position %d",
> + call_cntr)));
>
> I'm not sure if erroring out is the proper approach here. Won't this
> mean that with a newer openssl version on the client side, the
> function will potentially simply error out instead of returning proper
> results?

In one of the previous messages we've decided to report null rows in SRF
for such scenarios, and filter them out in SQL. I'm about to post the
new version with accumulated changes.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Nidzwetzki 2026-09-08 15:13:08 Add pg_nodiscard decorations to Bitmapset functions
Previous Message Ashutosh Bapat 2026-09-08 15:11:47 Re: Authorization semantics and candidate pruning in GRAPH_TABLE