On Sat, Dec 13, 2025 at 8:59 AM Peter Eisentraut <[email protected]> wrote: > > On 20.11.25 18:19, Melanie Plageman wrote: > > + prstate->deadoffsets = (OffsetNumber *) presult->deadoffsets; > > In your patch > v22-0001-Split-heap_page_prune_and_freeze-into-helpers.patch, the > assignment above casts away the const qualification of the function > argument presult:
Yea, this code (prune_freeze_setup() with a const-qualified PruneFreezeResult parameter) is actually already in master -- not just in this patchset. > +static void > +prune_freeze_setup(PruneFreezeParams *params, > + TransactionId new_relfrozen_xid, > + MultiXactId new_relmin_mxid, > + const PruneFreezeResult *presult, > + PruneState *prstate) > > (The cast is otherwise unnecessary, since the underlying type is the > same on both sides.) > > Since prstate->deadoffsets is in fact later modified, this makes the > original const qualification invalid. I didn't realize I was misusing const here. What I meant to indicate by defining the prune_freeze_setup() parameter, as const, is that the PruneFreezeResult wouldn't be modified by prune_freeze_setup(). I did not mean to indicate that no members of PruneFreezeResult would ever be modified. deadoffsets is not modified in prune_freeze_setup(). So, are you saying that I can't define a parameter as const if even the caller modifies it? I'm fine with committing a change, I just want to understand. - Melanie
