This has been committed.
On 09.12.24 16:44, Peter Eisentraut wrote:
> In [0] I wrote:
>
> """
> I was fiddling a bit with making some Page-related APIs const-proof,
> which might involve changing something like "Page p" to "const PageData
> *p", but I was surprised that a type PageData exists but it's an
> unrelated type local to generic_xlog.c.
>
> This patch renames that type to a more specific name
> [GenericXLogPageData]. This makes room for possibly adding another
> PageData type with the earlier meaning, but that's not done here.
>
> """
>
> [0]: https://www.postgresql.org/message-id/flat/001d457e-c118-4219-8132-
> e1846c2ae3c9%40eisentraut.org
>
> This is now the follow-up that adds back PageData with the earlier
> meaning and updates a few of the Page-related APIs to be const-proof.
> That is all pretty straightforward, except one inline function that had
> to be changed back to a macro, because it is used in a way that
> sometimes it takes const and returns const and sometimes takes non-const
> and returns non-const. (We might be able to do that kind of thing
> better with C23 in N years. ;-) )
>
> Just a thought, I've been thinking it might be neat if PageData were
> actually defined something like this:
>
> typedef struct PageData
> {
> union
> {
> PageHeaderData phdr;
> PGAlignedBlock data;
> };
> } PageData;
>
> Then you could write all those (PageHeader) casts in a more elegant way,
> and you don't get to randomly mix char * and Page, which has very weak
> type safety. But this currently totally breaks, because many places
> assume you can do char-based pointer arithmetic with Page values. So
> this would need further analysis.
