Re: Allow table AMs to define their own reloptions

Hi Hackers,

While testing dummy_table_am (src/test/modules/dummy_table_am/), I noticed
the README doesn't match the code

README says

dummy_table_am behaves like a heap table but accepts a different
set of reloptions:

- "fillfactor" (inherited from the core heap registration via
add_reloption_to_kind)
- "option_int" (integer)
- "option_real" (real)
- "option_bool" (boolean)
- "option_enum" (enum, one|two)

Standard heap options such as parallel_workers, autovacuum_*, and
toast_tuple_target are intentionally NOT accepted.

But create_reloptions_table() in dummy_table_am.c registers 8 standard
options: fillfactor, toast_tuple_target, parallel_workers,
vacuum_index_cleanup,
vacuum_truncate, vacuum_max_eager_freeze_failure_rate,
autovacuum_enabled, and user_catalog_table

Do we need to update documentation as per create_reloptions_table()?

Thanks & Best Regards,
Ajit

On Mon, 31 Aug 2026 at 17:57, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:

>
> On 2026-08-28 Fr 3:43 PM, Andrew Dunstan wrote:
> >
> > rebased patch attached.
> >
> Attached is v7. Changes since v6:
>
> - ALTER TABLE ... SET ACCESS METHOD skipped reloption revalidation when
> the new AM has no option parser of its own, on the theory that falling
> back to the heap parser meant nothing could have changed. But the
> old AM may have accepted options heap doesn't know, so e.g. switching a
> dummy_table_am table back to heap with option_int still set silently
> kept an option the next relcache load couldn't interpret. Validate
> unconditionally, with a test covering that direction.
> - DefineRelation validated a partition's reloptions against the wrong AM
> when the partitioned parent has no AM of its own (relam = 0): the
> validation lookup stopped at get_rel_relam(parent) while the actual
> relation creation falls back to default_table_access_method. With a
> non-heap default AM, PARTITION OF ... WITH (am_specific_option) was
> spuriously rejected. Apply the same fallback, with a test.
> - dummy_table_am registered autovacuum_enabled as a bool reloption; core
> defines it as ternary. Also rewrote the comments explaining why every
> standard option must be registered (the has_std_options_prefix
> contract), which were more confusing than helpful.
>
> cheers
>
>
> andrew
>
>
> --
> Andrew Dunstan
> EDB: https://www.enterprisedb.com
>