Re: Mark ItemPointer arguments as const thoughoutly

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Mark ItemPointer arguments as const thoughoutly
Date: 2025-10-30 13:30:56
Message-ID: 75d4e2c0-9d5d-4829-a1bd-7a84cd48ead4@eisentraut.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 26.09.25 04:54, Chao Li wrote:
> On Wed, Sep 10, 2025 at 1:20 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com
> <mailto:li(dot)evan(dot)chao(at)gmail(dot)com>> wrote:
>
>> On Sep 10, 2025, at 12:20, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com
>> <mailto:li(dot)evan(dot)chao(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2025-10-30 13:31:33 Re: doc: Improve description of io_combine_limit and io_max_combine_limit GUCs
Previous Message Joe Conway 2025-10-30 13:29:46 Re: contrib/sepgsql regression tests have been broken for months