From: | Japin Li <japinli(at)hotmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Peter Smith <smithpb2250(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: IndexAmRoutine aminsertcleanup function can be NULL? |
Date: | 2025-07-23 04:07:56 |
Message-ID: | ME0P300MB0445C9CAD215017BA2B7C4C8B65FA@ME0P300MB0445.AUSP300.PROD.OUTLOOK.COM |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 22 Jul 2025 at 14:36, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> On Thu, Jul 17, 2025 at 01:34:42PM +0800, Japin Li wrote:
>> On Wed, 16 Jul 2025 at 10:08, Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
>>> What's going on there? Is it just an accidentally missing "/* can be
>>> NULL */" comment?
>>
>> It appears commit c1ec02be1d79 is missing the comment.
>
> Agreed. That's user-visible, so backpatched down to v17.
>
>> How about asserting the existence of all required callbacks, similar to
>> GetTableAmRoutine()?
>
> Hmm, we could do something like that to enforce a stronger policy,
> yes. At least that seems sensible to me to be able to detect faster a
> problem rather than waiting for the backend to report the issue with a
> crash when testing a dedicated code path where one of these callbacks
> is run. As a HEAD-only thing, of course.
>
> I was reading the page, and some of the functions in the docs are
> documented as optional with the matching NULL description. It is
> the case of aminsertcleanup as well, one paragraph above with the
> part about "may define".
PFA to assert all required IndexAM callbacks are present.
--
Regards,
Japin Li
Attachment | Content-Type | Size |
---|---|---|
0001-Assert-required-index-access-method-callbacks.patch | text/x-diff | 1.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Smith | 2025-07-23 04:07:59 | Re: [WIP]Vertical Clustered Index (columnar store extension) - take2 |
Previous Message | Amit Kapila | 2025-07-23 04:07:55 | Re: Conflict detection for update_deleted in logical replication |