Hi,
On 2019-06-25 16:15:17 -0400, Tom Lane wrote:
> Andres Freund <andres@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