From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Remove Item type |
Date: | 2025-09-29 10:20:00 |
Message-ID: | c75cccf5-5709-407b-a36a-2ae6570be766@eisentraut.org |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Continuing the theme of cleaning up old and weird stuff in the code, I
propose to remove the Item type. It's defined as
typedef Pointer Item;
(note that Pointer is char *), and its almost only use is as part of
PageAddItem*():
extern OffsetNumber PageAddItemExtended(Page page, Item item, Size size,
OffsetNumber offsetNumber, int flags);
The actual thing passed to PageAddItem*() is of some AM-specific type,
and so that forces casts in all calls, like
offnum = PageAddItem(page, (Item) tuple, tuplen, offnum, true, false);
So this type doesn't promote any type safety, but in fact sort of forces
the opposite.
And then we have the usual problem that this is a type that hides
pointerness, and so we can't add any qualifiers, which leads to some
unconstify nonsense.
(Also, Item is unrelated to ItemPointer, which seems confusing.)
Initially I considered creating some underlying type to point to like
ItemData, but that didn't seem useful. Ultimately, PageAddItem*() is
just a fancy memcpy(), and using void * is an idiomatic way to refer to
a generic chunk of memory. So I'm proposing to remove the Item type,
replace it with void * in function prototypes, and remove all the casts.
Extension authors can make their code backward compatible by replacing
PageAddItem(page, (Item) tuple, ...)
with
PageAddItem(page, (void *) tuple, ...)
Attachment | Content-Type | Size |
---|---|---|
0001-Remove-Item-type.patch | text/plain | 49.5 KB |
0002-Some-const-qualifications.patch | text/plain | 4.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Borisov | 2025-09-29 10:22:29 | Re: Improve the performance of Unicode Normalization Forms. |
Previous Message | Pavel Stehule | 2025-09-29 10:13:25 | Re: proposal: schema variables |