Re: Allow table AMs to define their own reloptions - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Allow table AMs to define their own reloptions
Date
Msg-id cd3fe808-90f1-424f-be92-14535ab91a76@dunslane.net
Whole thread
In response to Re: Allow table AMs to define their own reloptions  (Zsolt Parragi <zsolt.parragi@percona.com>)
List pgsql-hackers
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




pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: Direct TOAST v2, faster, smaller and no migration needed
Next
From: ahmed
Date:
Subject: Re: Use instr_time for pg_stat_database block read/write time counters