Re: Allow table AMs to define their own reloptions

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Junwang Zhao <zhjwpku(at)gmail(dot)com>, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com>, Julien Tachoires <julien(at)tachoires(dot)me>
Subject: Re: Allow table AMs to define their own reloptions
Date: 2026-08-31 12:27:15
Message-ID: a389c8ce-0063-43ae-a1d5-4fe4deb070ee@dunslane.net
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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

Attachment Content-Type Size
v7-0001-Add-amoptions-callback-to-table-access-methods.patch text/x-patch 64.8 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nick Ivanov 2026-08-31 12:32:25 Re: Possible race condition in pg_basebackup
Previous Message Andrey Borodin 2026-08-31 12:26:38 Protocol compression: a fourth design