Re: Remove unneeded cast in heap_xlog_lock.
Peter Eisentraut <peter@eisentraut.org>
From: Peter Eisentraut <peter@eisentraut.org>
To: Kirill Reshke <reshkekirill@gmail.com>
Cc: Álvaro Herrera <alvherre@kurilemu.de>, Richard Guo <guofenglinux@gmail.com>, Chao Li <li.evan.chao@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-08-29T05:23:27Z
Lists: pgsql-hackers
On 28.08.25 10:08, Kirill Reshke wrote: > On Sat, 23 Aug 2025 at 19:57, Peter Eisentraut <peter@eisentraut.org> wrote: >> >> On 22.08.25 11:59, Álvaro Herrera wrote: >>> On 2025-Aug-22, Kirill Reshke wrote: >>> >>>> I am uncertain about the delineation between when we make changes and >>>> when we refrain from doing so. >>> >>> I think this is natural work after 9c727360bcc7, before which >>> BufferGetPage() was a macro and strangely enough had its own cast >>> embedded. As I understand, the less casts we have, the better. There's >>> some other standardization work going on to remove unnecessary casts >>> elsewhere, so I'm not sure why we wouldn't do this. >> >> In the very first code import, BufferGetPage() was a regular function >> that returned Page. (I suppose it was then turned into a macro, and >> then back into an inline function.) Even in that first code import, >> some callers cast the return to (Page), and some not. So I suppose this >> style just crept in for some random and ancient reason and then got >> copied around inconsistently. > > Thank you for clarifications. > >> We should clean it up. Casts are bad. > > I created CF [0] for this. > > [0] https://commitfest.postgresql.org/patch/6006/ committed
Commits
-
Remove unneeded casts of BufferGetPage() result
- 710e6c4301ee 19 (unreleased) landed