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

From: Priyanka S <developerette(at)gmail(dot)com>
To: Jinqing Kuang <kuangjinqingcn(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-09 07:41:53
Message-ID: CA+Db6gb1utGAxoeES4pfGotR1-ttX+XmeUi-WRaTwTk-eoTu1g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Jinqing,

Thanks for your explanation. I was not aware of the possibility of defining
custom strategies for GiST, SP-GiST and BRIN. I'll withdraw the patch for
rework.

Thanks & regards,
Priyanka

On Tue, Sep 8, 2026 at 1:47 PM Jinqing Kuang <kuangjinqingcn(at)gmail(dot)com>
wrote:

> > 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 Michael Paquier 2026-09-09 07:43:50 Re: pgstat: Flush some statistics within running transactions, take 2
Previous Message Xuneng Zhou 2026-09-09 07:30:22 Re: Reject WAIT FOR earlier in transaction-snapshot mode