Re: [PATCH] Log details for client certificate failures - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [PATCH] Log details for client certificate failures
Date
Msg-id 20220719223823.pj4z36ce3zb27qdb@alap3.anarazel.de
Whole thread Raw
In response to Re: [PATCH] Log details for client certificate failures  (Jacob Champion <jchampion@timescale.com>)
Responses Re: [PATCH] Log details for client certificate failures
List pgsql-hackers
Hi,

On 2022-07-19 15:08:38 -0700, Jacob Champion wrote:
> v2 adds escaping to pg_clean_ascii(). My original attempt used
> StringInfo allocation, but that didn't play well with guc_malloc(), so
> I switched to a two-pass API where the caller allocates. Let me know
> if I'm missing something obvious; this way is more verbose than I'd
> like...

Hm, that's pretty awkward. Perhaps we can have a better API for
everything but guc.c?

Or alternatively, perhaps we can just make pg_clean_ascii() return NULL
if allocation failed and then guc_strdup() the result in guc.c?

If we end up needing a two phase approach, why use the same function for
both phases? That seems quite awkward.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Re: [PATCH] Log details for client certificate failures
Next
From: Andres Freund
Date:
Subject: Re: pgsql: Default to hidden visibility for extension libraries where possi