Re: Remove unneeded cast in heap_xlog_lock.

2025-08-28 Thread Peter Eisentraut
On 28.08.25 10:08, Kirill Reshke wrote: On Sat, 23 Aug 2025 at 19:57, Peter Eisentraut 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

Re: Remove unneeded cast in heap_xlog_lock.

2025-08-28 Thread Kirill Reshke
On Sat, 23 Aug 2025 at 19:57, Peter Eisentraut 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

Re: Remove unneeded cast in heap_xlog_lock.

2025-08-23 Thread Peter Eisentraut
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

Re: Remove unneeded cast in heap_xlog_lock.

2025-08-22 Thread Richard Guo
On Fri, Aug 22, 2025 at 6:59 PM Á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 a

Re: Remove unneeded cast in heap_xlog_lock.

2025-08-22 Thread Chao Li
> On Aug 22, 2025, at 13:36, Kirill Reshke wrote: > > > I do not insist on this modification. I just spotted two completely > same codes in [0] & [1], which only differ in BufferGetPage cast. And > I merely tried to do something with it. > > v2 attached with all 69 casts removed, but I see th

Re: Remove unneeded cast in heap_xlog_lock.

2025-08-22 Thread Álvaro Herrera
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,

Re: Remove unneeded cast in heap_xlog_lock.

2025-08-21 Thread Kirill Reshke
On Fri, 22 Aug 2025 at 06:41, Richard Guo wrote: > > If you run 'git grep', you'll find a lot more instances where the > result of BufferGetPage() is explicitly cast to Page. > > git grep -rn "(Page) BufferGetPage" | wc -l > 69 > > Although these casts are unnecessary for sure, I'm not sure if it'

Re: Remove unneeded cast in heap_xlog_lock.

2025-08-21 Thread Michael Paquier
On Fri, Aug 22, 2025 at 10:41:15AM +0900, Richard Guo wrote: > Although these casts are unnecessary for sure, I'm not sure if it's > worth making the code changes to fix them. That's sort of the point. This is not code that needs to be fixed, because it's not broken. -- Michael signature.asc De

Re: Remove unneeded cast in heap_xlog_lock.

2025-08-21 Thread Richard Guo
On Fri, Aug 22, 2025 at 9:44 AM Chao Li wrote: > On Aug 21, 2025, at 22:10, Kirill Reshke wrote: > I was looking at how PostgreSQL handles VM map bits, when I noticed $subj. > PFA small refactoring patch. > LGTM. BufferGetPage() returns a “Page” type, and the receiving variable > “page” is of “

Re: Remove unneeded cast in heap_xlog_lock.

2025-08-21 Thread Chao Li
> On Aug 21, 2025, at 22:10, Kirill Reshke wrote: > > Hi! > > I was looking at how PostgreSQL handles VM map bits, when I noticed $subj. > PFA small refactoring patch. > > -- > Best regards, > Kirill Reshke > LGTM. BufferGetPage() returns a “Page” type, and the receiving variable “page”