Allow table AMs to define their own reloptions

Lists: pgsql-hackers
From: Julien Tachoires <julien(at)tachoires(dot)me>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Allow table AMs to define their own reloptions
Date: 2025-03-02 08:56:41
Message-ID: [email protected]
Views: Whole Thread | Raw Message | Download mbox | Resend email
Lists: pgsql-hackers

Hi,

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

--
Julien Tachoires

Attachment Content-Type Size
v1-0001-Allow-table-AMs-to-define-their-own-reloptions.patch text/x-diff 25.0 KB
v1-0002-Add-the-dummy_table_am-test-module.patch text/x-diff 33.3 KB

From: Julien Tachoires <julien(at)tachoires(dot)me>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Allow table AMs to define their own reloptions
Date: 2025-03-02 13:23:54
Message-ID: [email protected]
Views: Whole Thread | Raw Message | Download mbox | Resend email
Lists: pgsql-hackers

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'

--
Julien Tachoires

Attachment Content-Type Size
v2-0001-Allow-table-AMs-to-define-their-own-reloptions.patch text/x-diff 25.0 KB
v2-0002-Add-the-dummy_table_am-test-module.patch text/x-diff 33.3 KB

From: Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>
To: 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: 2025-03-02 15:20:07
Message-ID: [email protected]
Views: Whole Thread | Raw Message | Download mbox | Resend email
Lists: pgsql-hackers

02.03.2025 16:23, Julien Tachoires пишет:
> 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'

Good day, Julien.

Your forgot another one attempt discussion with patch [1] with alive
commitfest entry [2]

[1] https://postgr.es/m/flat/3766675.7eaCOWfIcx%40thinkpad-pgpro
[2] https://commitfest.postgresql.org/patch/4688/

-------
regards
Yura Sokolov aka funny-falcon


From: Julien Tachoires <julien(at)tachoires(dot)me>
To: Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Allow table AMs to define their own reloptions
Date: 2025-03-04 06:16:19
Message-ID: [email protected]
Views: Whole Thread | Raw Message | Download mbox | Resend email
Lists: pgsql-hackers

Hi Yura,

On Sun, Mar 02, 2025 at 06:20:07PM +0300, Yura Sokolov wrote:
> Your forgot another one attempt discussion with patch [1] with alive
> commitfest entry [2]
>
> [1] https://postgr.es/m/flat/3766675.7eaCOWfIcx%40thinkpad-pgpro
> [2] https://commitfest.postgresql.org/patch/4688/

Thank you. After taking a look at the patch itself and the email thread,
it seems this patch does not add custom reloptions to table AMs, see
[1].

[1]: https://www.postgresql.org/message-id/1823308.yXV3o4JbTB%40thinkpad-pgpro

--
Julien Tachoires


From: Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>
To: Julien Tachoires <julien(at)tachoires(dot)me>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Allow table AMs to define their own reloptions
Date: 2025-03-04 09:19:53
Message-ID: [email protected]
Views: Whole Thread | Raw Message | Download mbox | Resend email
Lists: pgsql-hackers

04.03.2025 09:16, Julien Tachoires пишет:
> Hi Yura,
>
> On Sun, Mar 02, 2025 at 06:20:07PM +0300, Yura Sokolov wrote:
>> Your forgot another one attempt discussion with patch [1] with alive
>> commitfest entry [2]
>>
>> [1] https://postgr.es/m/flat/3766675.7eaCOWfIcx%40thinkpad-pgpro
>> [2] https://commitfest.postgresql.org/patch/4688/
>
> Thank you. After taking a look at the patch itself and the email thread,
> it seems this patch does not add custom reloptions to table AMs, see
> [1].
>
> [1]: https://www.postgresql.org/message-id/1823308.yXV3o4JbTB%40thinkpad-pgpro

But intention of this patch is to make adding options easier, as author says:

But new option engine will make adding custom options for table AM more
easy task, as main goal of this patch is to simplify adding options
everywhere they needed. And yes, adding custom table AM options is one of
my next goals, as soon as this patch is commit.

I believe, adding generic way to options extension is better way than
targeting specific options. Don't you?

I believe Nikolay's patch needs review and support. As you're interesting
to the problem, may you at least look at his suggestion and analyze it from
the point of view of your task?

-------
regards
Yura Sokolov aka funny-falcon


From: Julien Tachoires <julien(at)tachoires(dot)me>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Allow table AMs to define their own reloptions
Date: 2025-03-29 07:46:01
Message-ID: [email protected]
Views: Whole Thread | Raw Message | Download mbox | Resend email
Lists: pgsql-hackers

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.

--
Julien Tachoires

Attachment Content-Type Size
v3-0001-Allow-table-AMs-to-define-their-own-reloptions.patch text/x-diff 25.0 KB
v3-0002-Add-the-dummy_table_am-test-module.patch text/x-diff 33.1 KB

From: Julien Tachoires <julien(at)tachoires(dot)me>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Allow table AMs to define their own reloptions
Date: 2025-05-26 11:06:19
Message-ID: [email protected]
Views: Whole Thread | Raw Message | Download mbox | Resend email
Lists: pgsql-hackers

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.

--
Julien Tachoires

Attachment Content-Type Size
v4-0001-Allow-table-AMs-to-define-their-own-reloptions.patch text/x-diff 25.0 KB
v4-0002-Add-the-dummy_table_am-test-module.patch text/x-diff 33.1 KB