Re: Allow table AMs to define their own reloptions

On 2026-10-11 Su 6:26 PM, Zsolt Parragi wrote:
>> That requires AMs to inherit standard option names rather than
>> redefine
> It looks a lot better this way, but shouldn't the documentation
> mention somewhere that AMs that don't do this, like
> dummy_custom_table_am can fail to restore --no-table-access-method
> dumps from other AMs?
>
> +
> +/* The standard options, all of which dummy_table_am accepts */
> +static const relopt_parse_elt dt_std_options[] = {
> + {"fillfactor", RELOPT_TYPE_INT,
> + offsetof(struct DummyTableOptions, std.fillfactor)},
>
> and
>
> + for (int j = 0; j < lengthof(dt_std_options); j++)
> + {
> + add_reloption_to_kind(dt_std_options[j].optname, dt_relopt_kind);
> + dt_relopt_tab[i++] = dt_std_options[j];
> + }
> +
>
> Wouldn't a helper be useful for this based on / around
> stdRdOptionsTab, so that it doesn't require this much fragile
> copy-pasting?

Hi, thanks (again) for the review. here's a v13 that I think addresses
your points.

Changes since v12:
  - 0001: new add_std_reloptions_to_kind(), which makes all the
    standard options valid for an AM's relopt_kind and copies their
    parse table entries, for an AM whose options struct begins with a
    StdRdOptions.  NUM_STD_RELOPTIONS gives the number of entries, and
    a static assertion keeps it in step with stdRdOptionsTab.
    dummy_table_am uses it instead of its own copy of the table.
  - 0001: fix tableam.h comments that referred to the old title of the
    documentation section.
  - 0002: tableam.sgml now says that a --no-table-access-method dump
    can only be restored if the default access method accepts every
    standard option set on the dumped tables, so an AM that supplies
    amoptions should accept them all unless it has a good reason not to.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com