Re: Allow table AMs to define their own reloptions

On 2026-09-30 We 5:22 PM, Zsolt Parragi wrote:
> pg_dump has the option "--no-table-access-method". Should that somehow
> interact with this feature? As currently that can result in non
> restorable dumps.
>

Good catch.

Worse, the CREATE TABLE fails, so the table and its data are lost,
with both pg_dump and pg_restore --no-table-access-method.

We can't just move the options to a later ALTER TABLE, because some
standard ones (toast_value_type) only matter at creation time. So my
plan, as a second patch:

- A function pg_reloption_is_standard(name), true if the option is
  registered for RELOPT_KIND_HEAP (including ones an AM inherits via
  add_reloption_to_kind()).

- For non-heap tables and matviews, pg_dump keeps standard options in
  the CREATE, and puts AM-specific ones in a separate ALTER TABLE ...
  SET (...) TOC entry, which --no-table-access-method omits or skips.

- TAP tests using dummy_table_am.

That requires AMs to inherit standard option names rather than
redefine them, and to have their own options work when set by ALTER
TABLE on an empty table, since every restore would apply them that
way. I'd document both in tableam.sgml. The second one isn't ideal,
but I don't see a simpler way. Better ideas welcome.

>
> There's also one more limitation similar to the TEXT issue I reported
> upthread - and similarly it's not an issue for current tests, but
> might be worth improving:
>
> /* src: src/backend/access/heap/heapam.c:1449-1452 */
> if (unlikely(sscan->rs_rd->rd_tableam != GetHeapamTableAmRoutine()))
> ereport(ERROR, ... errmsg_internal("only heap AM is supported")));
>
> CREATE TABLE ti (a int) USING dummy_table_am;
> CREATE INDEX ON ti(a); -- ERROR:
> only heap AM is supported
>
> CREATE TABLE tp (a int PRIMARY KEY) USING dummy_table_am; -- ERROR:
> only heap AM is supported

Same cause as the TOAST issue: heap_getnext() requires the heap routine
itself, and dummy_table_am has to copy it to substitute amoptions.
Working around it for index builds would mean reimplementing heap's
index build scan in the module, which doesn't seem worthdoing for this
dummy whose only purpose is to test handling options. So I'll just note
the restriction in the README. We might need to revisit it if we want
to make the dummy AM do more.

cheers

andrew

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