Re: Remove unneeded cast in heap_xlog_lock. - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Remove unneeded cast in heap_xlog_lock.
Date
Msg-id 06c7c271-c2fd-4635-8115-929e2f4b8437@eisentraut.org
Whole thread Raw
In response to Re: Remove unneeded cast in heap_xlog_lock.  (Kirill Reshke <reshkekirill@gmail.com>)
List 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




pgsql-hackers by date:

Previous
From: shveta malik
Date:
Subject: Re: Improve pg_sync_replication_slots() to wait for primary to advance
Next
From: Peter Eisentraut
Date:
Subject: Re: Mark ItemPointer parameters as const in tuple/table lock functions