Re: Reloptions for table access methods

On Tue, 2020-12-15 at 17:37 +0000, Simon Riggs wrote:
>
> I definitely don't agree with the premise that all existing heap
> options should be common across all new or extension tableAMs. There
> are dozens of such options and I don't believe that they would all
> have meaning in all future storage plugins.

I agree in principle, but looking at the options that are present
today, a lot of them are integrated into general database features,
like autovacuum, toast, logical replication, and parellel query
planning.

We need to have some answer about how these features should interact
with a custom AM if we can't assume anything about the reloptions it
understands.

> I think options should just work exactly the same for Indexes and
> Tables.

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 feels like some common options would make sense to avoid too much
code duplication.

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.

Regards,
Jeff Davis