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
signature.asc
Description: PGP signature
