On Tue, 20 May 2025, 22:14 Peter Geoghegan, <p...@bowt.ie> wrote: > > On Mon, May 12, 2025 at 8:58 AM Peter Geoghegan <p...@bowt.ie> wrote: > > I wonder if we can fix this problem by getting rid of the old support > > routine #5, "options". It currently doesn't do anything, and I always > > thought it was strange that it was added "for uniformity" with other > > index AMs. > > Attached patch completely removes the nbtree "options" support > function, while changing the support function number of skip support: > it becomes support function #5 (the number previously used by > "options"). This patch should fix the regression that Tomas complained > about in an expedient way.
> It's likely that somebody else will run into the same problem in the > future, the next time that a new support function is needed. But I > think that it makes sense to do this much now -- we need a short term > solution for Postgres 18. Didn't we have different solutions already? E.g. dropping the allocation requirement from IndexAM (and indeed, making it non-required), as seen in my 0001? It's a bit of a hassle, but has shown to have the same effect in PG18b1, doesn't break compatibility with existing amproc registrations, and even improves the memory situation for all other index types. > Usually I would never suggest breaking > compatibility like this, but, remarkably, we have never actually done > anything with our current support function 5. It's not possible to > break compatibility with code that can never be called in the first > place, so I see no compatibility to preserve. I disagree. An extension or user may well have registered FUNCTION 5 for their opclass or opfamily as blanket future-proofed implementation, which will now break after pg_upgrade. We never rejected this registration before, and while there won't be issues with the proc signature across the versions (options' expected signature is equivalent to that of skipsupport), it will probably cause issues when it's called with unexpected inputs. Kind regards, Matthias van de Meent Neon (https://neon.tech)
