Re: Mark ItemPointer parameters as const in tuple/table lock functions - Mailing list pgsql-hackers

From Chao Li
Subject Re: Mark ItemPointer parameters as const in tuple/table lock functions
Date
Msg-id CAEoWx2=-FPRo-5v1f=ZTrLvhhXRvLPFbnyrjzrmPvoSMdRF2tw@mail.gmail.com
Whole thread Raw
In response to Re: Mark ItemPointer parameters as const in tuple/table lock functions  (Chao Li <li.evan.chao@gmail.com>)
List pgsql-hackers
Mail Archive always misses attachments sent by Apple Mail. Resending from the Gmail web client.

Chao Li (Evan)
---------------------
Highgo Software Co., Ltd.
https://www.highgo.com/


Chao Li <li.evan.chao@gmail.com> 于2025年8月28日周四 10:28写道:


On Aug 27, 2025, at 17:24, Peter Eisentraut <peter@eisentraut.org> wrote:

This style of having Foo be a type alias for pointer-to-FooData is an ancient Postgres coding convention that does not map well to modern C that has an emphasis on judicious use of qualifiers and attributes, and so if this abstraction gets in the way, we sometimes crack it open, like in the case of ItemPointerGetBlockNumber() etc.

You are right, we want to protect the stuff that “tid” points to instead of “tid” itself:

     *tid = something; // should hit compile error
     tid = something; // ok

Also, thanks for telling the history. I have updated the patch to use “const ItemPointerData *” in the same way as ItemPointerGetBlockNumber().

Attached is the v2 patch.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/




Attachment

pgsql-hackers by date:

Previous
From: Chao Li
Date:
Subject: Re: Mark ItemPointer parameters as const in tuple/table lock functions
Next
From: "Zhijie Hou (Fujitsu)"
Date:
Subject: RE: Conflict detection for update_deleted in logical replication