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