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 <[email protected]> wrote: > > On Aug 3, 2026, at 22:35, Priyanka S <[email protected]> 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 > >
