Re: [Patch] Implement TODOs for index operator strategy number validation

From: Jinqing Kuang <kuangjinqingcn(at)gmail(dot)com>
To: Priyanka S <developerette(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [Patch] Implement TODOs for index operator strategy number validation
Date: 2026-09-08 08:17:25
Message-ID: 14FB7D28-9BEE-4FFE-9FB8-A75BF97D4C11@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Aug 3, 2026, at 22:35, Priyanka S <developerette(at)gmail(dot)com> wrote:
>
> Hi,
>
> This patch implements TODOs in the BRIN, GIN, GIST and SP-GIST index code. Operator class validation is modified to add strategy number bounds checking specific to each index type.
> 1) For BRIN and SP-GIST, the maximum strategy number from the common RTStrategy list is used as the upper limit.
> 2) For SP-GIST, the number of GIS object types and the strategy numbers per type are used to calculate the maximum strategy number.
> 3) As far as I can understand from the code, GIN may have custom strategies, so the existing limit of 63 is retained.
>
> I have tested this patch using 'make check' and 'make worldcheck'. All the tests pass.
>
> This is my first contribution, so any input would be appreciated.
>
> Thanks & regards,
> Priyanka
> <0001-Fix-TODOs-for-index-opclass-strategy-number-validati.patch>

Hi Priyanka,

Thanks for the patch. I have a concern about the new strategy-number
bounds.

GiST, SP-GiST and BRIN all set amstrategies = 0, meaning that strategy
numbers are opclass-defined (see amapi.h and DefineOpClass()).

For example, a custom SP-GiST opclass can use strategy 31 if its support
functions understand it, but this patch would make amvalidate() reject
it. RTMaxStrategyNumber isn't a general limit for BRIN/SP-GiST, and
the Geo* constants are specific to the built-in GiST point implementation.

Regards,
Jinqing

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2026-09-08 08:48:29 Re: FOR PORTION OF bounds not coerced in PREPARE
Previous Message Daniel Gustafsson 2026-09-08 08:17:19 Re: Offline data checksum changes can cause incorrect checksum state on standbys