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 a389c8ce-0063-43ae-a1d5-4fe4deb070ee@dunslane.net
Whole thread
In response to Re: Allow table AMs to define their own reloptions  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Allow table AMs to define their own reloptions
Re: Allow table AMs to define their own reloptions
List 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

pgsql-hackers by date:

Previous
From: Andrey Borodin
Date:
Subject: Protocol compression: a fourth design
Next
From: Nick Ivanov
Date:
Subject: Re: Possible race condition in pg_basebackup