On Tue, 15 Dec 2020 at 23:59, Jeff Davis <pgsql@j-davis.com> wrote:
>
> 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.
Your argument seems to be that all new Table AMs should offer some
kind of support for these "standard" options, even if it is to accept
and then ignore them, which would presumably require them to document
that. If that is the case, then at very least offer a doc patch that
says that so people know what to do and doc comments describe how we
should treat new parameters in the future.
But you cannot seriously argue that a one line patch that changes user
visible behavior can be acceptable in Postgres core without tests or
docs or code comments. You know as a Committer that that position is
not sustainable.
Minor changes could be OK if they are complete. Please either push
forward to a usable commit or withdraw, so other options can be
considered.
--
Simon Riggs http://www.EnterpriseDB.com/