Re: Add ssl_(supported|shared)_groups to sslinfo - Mailing list pgsql-hackers

From Dmitry Dolgov
Subject Re: Add ssl_(supported|shared)_groups to sslinfo
Date
Msg-id aqAlC4G8bTekShA5@ddolgov-thinkpadt14sgen1.rmtde.csb
Whole thread
In response to Re: Add ssl_(supported|shared)_groups to sslinfo  (Zsolt Parragi <zsolt.parragi@percona.com>)
Responses Re: Row pattern recognition
List 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.



Attachment

pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Authorization semantics and candidate pruning in GRAPH_TABLE
Next
From: Jan Nidzwetzki
Date:
Subject: Add pg_nodiscard decorations to Bitmapset functions