Re: Mark ItemPointer arguments as const thoughoutly - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Mark ItemPointer arguments as const thoughoutly
Date
Msg-id 75d4e2c0-9d5d-4829-a1bd-7a84cd48ead4@eisentraut.org
Whole thread Raw
In response to Re: Mark ItemPointer arguments as const thoughoutly  (Chao Li <li.evan.chao@gmail.com>)
Responses Re: Mark ItemPointer arguments as const thoughoutly
List pgsql-hackers
On 26.09.25 04:54, Chao Li wrote:
> On Wed, Sep 10, 2025 at 1:20 PM Chao Li <li.evan.chao@gmail.com 
> <mailto:li.evan.chao@gmail.com>> wrote:
> 
>>     On Sep 10, 2025, at 12:20, Chao Li <li.evan.chao@gmail.com
>>     <mailto:li.evan.chao@gmail.com>> wrote:
>>
>>     v2 tries to fix the CI failure.
>>
>>     Chao Li (Evan)
>>     ---------------------
>>     HighGo Software Co., Ltd.
>>     https://www.highgo.com/ <https://www.highgo.com/>
>>
>>     <v2-0001-Mark-ItemPointer-arguments-as-const-thoughoutly.patch>
> 
>     Here is the CF patch https://commitfest.postgresql.org/patch/6046/
>     <https://commitfest.postgresql.org/patch/6046/>, and the CI tests
>     passed.

I have committed most of this patch.

I didn't like the few places in itemptr.h where you changed an existing 
ItemPointerData* back to ItemPointer, so I left those out.

More importantly, some of the proposed changes change the signatures of 
callback functions in the index or table AM APIs.  (And also the 
documentation wasn't updated.)  This would break source code 
compatibility with existing extensions that use those APIs.  There are 
have been previous proposals like this in [0], [1] where the changes to 
those APIs were not committed.  And your other patch 'Mark function 
arguments of type "Datum *" as "const Datum *" where possible' might 
have similar problems (although it looks like it's touching different 
places than [0] and [1]).  So I left those changes out of what I committed.

That doesn't mean we can never change these APIs.  We certainly change 
many backend APIs all the time, and extensions providing table or index 
AMs are sophisticated and will need to make adjustments anyway.  But it 
would be better if we did any changes in a deliberate way with explicit 
notice and advice for extensions (like commit 76acf4b722f for example).

[0]: 
https://www.postgresql.org/message-id/flat/14c31f4a-0347-0805-dce8-93a9072c05a5%40eisentraut.org
[1]: 
https://www.postgresql.org/message-id/flat/f8c739d9-f48d-4187-b214-df3391ba41ab%40eisentraut.org



pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: contrib/sepgsql regression tests have been broken for months
Next
From: Fujii Masao
Date:
Subject: Re: doc: Improve description of io_combine_limit and io_max_combine_limit GUCs