From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Kirill Reshke <reshkekirill(at)gmail(dot)com> |
Cc: | Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Richard Guo <guofenglinux(at)gmail(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Remove unneeded cast in heap_xlog_lock. |
Date: | 2025-08-29 05:23:27 |
Message-ID: | 06c7c271-c2fd-4635-8115-929e2f4b8437@eisentraut.org |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 28.08.25 10:08, Kirill Reshke wrote:
> On Sat, 23 Aug 2025 at 19:57, Peter Eisentraut <peter(at)eisentraut(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2025-08-29 05:42:41 | Re: Mark ItemPointer parameters as const in tuple/table lock functions |
Previous Message | shveta malik | 2025-08-29 05:01:39 | Re: Improve pg_sync_replication_slots() to wait for primary to advance |