Re: Confusing #if nesting in hmac_openssl.c

Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
> On 2 Apr 2024, at 02:01, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I don't think
>> it is helpful to put the resource owner manipulations inside #ifdef
>> HAVE_HMAC_CTX_NEW and HAVE_HMAC_CTX_FREE --- ...
>> What do you think of rearranging it as attached?

> +1 on this patch, it makes the #ifdef soup more readable.

Thanks for looking at it.

> We could go even
> further and remove the HAVE_HMAC defines completely with USE_RESOWNER_FOR_HMAC
> being set by autoconf/meson? I've attached an untested sketch diff to
> illustrate.

I'm inclined to think that won't work, because we need the HAVE_
macros separately to compile correct frontend code.

> A related tangent. If we assembled the data to calculate on ourselves rather
> than rely on OpenSSL to do it with subsequent _update calls we could instead
> use the simpler HMAC() API from OpenSSL. That would remove the need for the
> HMAC_CTX and resource owner tracking entirely and just have our pg_hmac_ctx.
> Thats clearly not for this patch though, just thinking out loud that we set up
> OpenSSL infrastructure that we don't really use.

Simplifying like that could be good, but I'm not volunteering.
For the moment I'd just like to silence the buildfarm warning,
so I'll go ahead with what I have.

regards, tom lane