Re: some Page/PageData const stuff

From: Andres Freund <andres(at)anarazel(dot)de>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: some Page/PageData const stuff
Date: 2026-01-03 17:23:01
Message-ID: gc7uslcthe5pmra56wazmo5gnqxlbpohsitrfugi55zvyhukgl@ied5awbjzpon
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2026-01-03 18:05:19 +0100, Peter Eisentraut wrote:
> On 02.01.26 20:17, Andres Freund wrote:
> > On 2025-01-20 15:01:08 +0100, Peter Eisentraut wrote:
> > > This has been committed.
> >
> > I don't like the const markings in PageGetItem():
> >
> >
> > /*
> > * PageGetItem
> > * Retrieves an item on the given page.
> > *
> > * Note:
> > * This does not change the status of any of the resources passed.
> > * The semantics may change in the future.
> > */
> > static inline void *
> > PageGetItem(const PageData *page, const ItemIdData *itemId)
> > {
> > Assert(page);
> > Assert(ItemIdHasStorage(itemId));
> >
> > return (void *) (((const char *) page) + ItemIdGetOffset(itemId));
> > }
> >
> > The const for PageData seems like a lie to me, because we cast it away. And
> > indeed, we often then use the returned value to set hint bits etc.
>
> I agree this is incorrect. Since no callers appear to rely on the const
> qualification of the argument, the easiest solution would be to just remove
> it. See attached patch.

LGTM

> (In the future, this might be a candidate for a qualifier-preserving
> polymorphic function like the C23 string functions, but that's for another
> day.)

Makes sense. I doubt this is the place I would start with that though, the
amount of effort that'd take around all the functions dealing with heap tuples
seems too large...

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2026-01-03 17:31:29 Re: Non-text mode for pg_dumpall
Previous Message Peter Eisentraut 2026-01-03 17:14:45 Re: remove pg_restrict workaround