Re: Reloptions for table access methods

On Tue, Dec 15, 2020 at 03:59:02PM -0800, Jeff Davis wrote:
> How should that work with the existing code? Should we have separate AM
> hooks for each of these interaction points, and then have the AM figure
> out how to handle its options? What about the toast.* options?

It seems to me that we would want a callback for options that is part
of TableAmRoutine to do the loading work, no? The bigger picture is
more complex than that though because all in-core AMs rely on
build_reloptions() to do the work which itself depends on a et of
pre-existing reloptions (all the static relOpts array). In the end,
I'd like to think that we should remove the dependency between relopt
build and initialization state, then switch all the different AMs to
do something similar to create_reloptions_table() in dummy_index_am.c
to define a new set of reloptions, except that we'd want to preload
all the options at backend startup or something similar to that for
all in-core AMs, for tables and indexes.

> It feels like some common options would make sense to avoid too much
> code duplication.

Having a set of options that can be plugged in to any AMs, like a set
of preset options for autovacuum or toast makes sense to have.

> I am not trying to push this in a specific direction, but I don't have
> a lot of good answers, so I went for the simplest thing I could think
> of that would allow an extension to have its own options, even if it's
> a bit hacky. I'm open to alternatives.

FWIW, I agree with Simon's feeling that bypassing a sanity check does
not feel like a good solution in the long term.
--
Michael