| 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
| 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 |