Re: Allow table AMs to define their own reloptions

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com>
Cc: Julien Tachoires <julien(at)tachoires(dot)me>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Allow table AMs to define their own reloptions
Date: 2026-07-16 14:32:46
Message-ID: CAD5tBcKJOUYZunmx=RVZh4MsxGOcY-ftAWhb63nNAntRWZ7XAw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jul 16, 2026 at 9:37 AM Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com>
wrote:

>
>
> On Thu, 4 Jun 2026 at 04:32, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
>>
>> On 2025-05-26 Mo 7:06 AM, Julien Tachoires wrote:
>> > On Sat, Mar 29, 2025 at 08:46:01AM +0100, Julien Tachoires wrote:
>> >> On Sun, Mar 02, 2025 at 02:23:54PM +0100, Julien Tachoires wrote:
>> >>> On Sun, Mar 02, 2025 at 09:56:41AM +0100, Julien Tachoires wrote:
>> >>>> With the help of the new TAM routine 'relation_options', table access
>> >>>> methods can with this patch define their own reloptions
>> >>>> parser/validator.
>> >>>>
>> >>>> These reloptions can be set via the following commands:
>> >>>> 1. CREATE TABLE ... USING table_am
>> >>>> WITH (option1='value1', option2='value2');
>> >>>> 2. ALTER TABLE ...
>> >>>> SET (option1 'value1', option2 'value2');
>> >>>> 3. ALTER TABLE ... SET ACCESS METHOD table_am
>> >>>> OPTIONS (option1 'value1', option2 'value2');
>> >>>>
>> >>>> When changing table's access method, the settings inherited from the
>> >>>> former TAM can be dropped (if not supported by the new TAM) via: DROP
>> >>>> option, or, updated via: SET option 'value'.
>> >>>>
>> >>>> Currently, tables using different TAMs than heap are able to use
>> heap's
>> >>>> reloptions (fillfactor, toast_tuple_target, etc...). With this patch
>> >>>> applied, this is not the case anymore: if the TAM needs to have
>> access
>> >>>> to similar settings to heap ones, they have to explicitly define
>> them.
>> >>>>
>> >>>> The 2nd patch file includes a new test module 'dummy_table_am' which
>> >>>> implements a dummy table access method utilized to exercise TAM
>> >>>> reloptions. This test module is strongly based on what we already
>> have
>> >>>> in 'dummy_index_am'. 'dummy_table_am' provides a complete example of
>> TAM
>> >>>> reloptions definition.
>> >>>>
>> >>>> This work is directly derived from SadhuPrasad's patch here [2].
>> Others
>> >>>> attempts were posted here [1] and here [3].
>> >>>>
>> >>>> [1]
>> https://www.postgresql.org/message-id/flat/429fb58fa3218221bb17c7bf9e70e1aa6cfc6b5d.camel%40j-davis.com
>> >>>> [2]
>> https://www.postgresql.org/message-id/flat/CAFF0-CG4KZHdtYHMsonWiXNzj16gWZpduXAn8yF7pDDub+GQMg(at)mail(dot)gmail(dot)com
>> >>>> [3]
>> https://www.postgresql.org/message-id/flat/AMUA1wBBBxfc3tKRLLdU64rb.1.1683276279979.Hmail.wuhao%40hashdata.cn
>> >>> Please find a new version including minor fixes: 'TAM' terms are
>> >>> replaced by 'table AM'
>> >> Please find a new rebased version.
>> > New rebased version.
>> >
>>
>>
>> This thread seems to have gone dormant, sadly. Here's a fresh attempt I
>> made (with assistance from Claude), before I was aware of the existence
>> of this and other efforts. I think it meets most of the previous
>> objections, and is in line with what we do for Index AMs.
>>
>> I was testing this patch and found this issue,
> CREATE EXTENSION dummy_table_am;
> CREATE TABLE t (a int) USING dummy_table_am WITH (option_int = 42);
> ALTER TABLE t SET ACCESS METHOD heap;
> SELECT reloptions FROM pg_class WHERE oid = 't'::regclass;
> reloptions
> -----------------
> {option_int=42}
> (1 row)
> ALTER TABLE t SET (fillfactor = 50);
> 2026-07-16 19:01:36.060 IST [95058] ERROR: unrecognized parameter
> "option_int"
> 2026-07-16 19:01:36.060 IST [95058] STATEMENT: ALTER TABLE t SET
> (fillfactor = 50);
> ERROR: unrecognized parameter "option_int"
>
> Basically, the option is left behind after changing the tableam to heap, I
> think that isn't intentional.
>
>>
>>
>

Thanks for reviewing. Good catch!

Basically the code had an early exit in the validation code that shouldn't
have been there.

v2 attached with a fix for that, plus a regression test covering this
direction (dummy_table_am -> heap with a still-set AM-specific option),
which I verified fails against v1 and passes with the fix. I also
folded the two independent access-method-resolution code paths in
DefineRelation into one and added the new test module's typedefs to
typedefs.list

cheers

andrew

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Anton Voloshin 2026-07-16 14:34:54 Re: NULL pointer dereference in syslogger with load_libraries() and -DEXEC_BACKEND at startup
Previous Message Daniel Gustafsson 2026-07-16 14:29:13 Re: [PATCH] pg_upgrade: add --initdb option to create the new cluster automatically