Re: pgsql: Make cancel request keys longer

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: Make cancel request keys longer
Date: 2025-04-09 08:53:20
Message-ID: 34d5d731-06cc-43af-88cd-b3a4c5c8d9df@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On 08/04/2025 22:41, Heikki Linnakangas wrote:
> On 08/04/2025 20:06, Peter Eisentraut wrote:
>> While I was looking at this, I suggest to make the first argument void
>> *.  This is consistent for passing binary data.
>
> Ok, sure.

On second thoughts, -1 on that. 'void *' is appropriate for functions
like libc's read() or pq_sendbytes(), where the buffer can point to
anything. In other words, the caller is expected to have a pointer like
'foobar *', and it gets cast to 'void *' when you call the function.
That's not the case with the cancellation key. The cancellation key is
just an array of bytes, the caller is expected to pass an array of
bytes, not a struct.

The right precedent for that are e.g. SCRAM functions in scram-common.h,
for example. They use "const uint8 *" for the hashes.

I'll switch to "const uint *" everywhere that deals with cancel keys.
There are a few more variables elsewhere in the backend and in libpq.

> Looks good to me. I can commit these tomorrow, or feel free to do it
> yourself too.

I'm on this now.

--
Heikki Linnakangas
Neon (https://neon.tech)

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Peter Eisentraut 2025-04-09 09:39:49 Re: pgsql: Make cancel request keys longer
Previous Message Daniel Gustafsson 2025-04-09 07:33:19 pgsql: Perform missed catversion bump

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2025-04-09 09:18:25 Re: Memoize ANTI and SEMI JOIN inner
Previous Message Laurenz Albe 2025-04-09 08:42:36 Re: [PATCH] New predefined role pg_manage_extensions