| 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.
| 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 |