Hi, On 2019-06-25 16:15:17 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > I think it might be worthwhile require that IndexAmRoutine returned by > > amhandler are allocated statically. > > +1. Could only be an issue if somebody were tempted to have time-varying > entries in them, but it's hard to see why that could be a good idea.
Yea, that seems like a use case we wouldn't want to support. If something like that is needed, they ought to store it in the relcache. > Should we enforce this for *all* handler objects? If only index AMs, > why only them? Well, tableams do that already. Other than indexam and tableam I think there's also FDW and TSM routines - are there any others? Changing the FDW API seems like it'd incur some work to a lot more people than any of the others - I'm not sure it's worth it. > > It seems to me like there's not that many index AMs out there, so > > changing the signature of amhandler() to require returning a const > > pointer to a const object ought to both be enough of a warning, and not > > too big a burden. > > One too many "consts" there. Pointer to const object seems fine. > The other part is either meaningless or will cause problems. Yea - I was thinking of the pointer in RelationData, where having it as const *Routine const; would make sense (but it's annoying to do without invoking technically undefined behaviour, doing ugly things with memcpy or duplicating struct definitions). Greetings, Andres Freund
