Allow table AMs to define their own reloptions

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] /messages/by-id/429fb58fa3218221bb17c7bf9e70e1aa6cfc6b5d.camel@j-davis.com
[2] /messages/by-id/CAFF0-CG4KZHdtYHMsonWiXNzj16gWZpduXAn8yF7pDDub+GQMg@mail.gmail.com
[3] /messages/by-id/AMUA1wBBBxfc3tKRLLdU64rb.1.1683276279979.Hmail.wuhao@hashdata.cn

Please find a new version including minor fixes: 'TAM' terms are
replaced by 'table AM'

--
Julien Tachoires

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] /messages/by-id/429fb58fa3218221bb17c7bf9e70e1aa6cfc6b5d.camel@j-davis.com
[2] /messages/by-id/CAFF0-CG4KZHdtYHMsonWiXNzj16gWZpduXAn8yF7pDDub+GQMg@mail.gmail.com
[3] /messages/by-id/AMUA1wBBBxfc3tKRLLdU64rb.1.1683276279979.Hmail.wuhao@hashdata.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]/messages/by-id/flat/3766675.7eaCOWfIcx@thinkpad-pgpro with alive
commitfest entry [2]https://commitfest.postgresql.org/patch/4688/

[1]: /messages/by-id/flat/3766675.7eaCOWfIcx@thinkpad-pgpro
[2]: https://commitfest.postgresql.org/patch/4688/

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

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] /messages/by-id/flat/3766675.7eaCOWfIcx@thinkpad-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]: /messages/by-id/1823308.yXV3o4JbTB@thinkpad-pgpro

[1]: /messages/by-id/1823308.yXV3o4JbTB@thinkpad-pgpro

--
Julien Tachoires

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] /messages/by-id/flat/3766675.7eaCOWfIcx@thinkpad-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]: /messages/by-id/1823308.yXV3o4JbTB@thinkpad-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

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] /messages/by-id/429fb58fa3218221bb17c7bf9e70e1aa6cfc6b5d.camel@j-davis.com
[2] /messages/by-id/CAFF0-CG4KZHdtYHMsonWiXNzj16gWZpduXAn8yF7pDDub+GQMg@mail.gmail.com
[3] /messages/by-id/AMUA1wBBBxfc3tKRLLdU64rb.1.1683276279979.Hmail.wuhao@hashdata.cn

Please find a new version including minor fixes: 'TAM' terms are
replaced by 'table AM'

Please find a new rebased version.

--
Julien Tachoires

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] /messages/by-id/429fb58fa3218221bb17c7bf9e70e1aa6cfc6b5d.camel@j-davis.com
[2] /messages/by-id/CAFF0-CG4KZHdtYHMsonWiXNzj16gWZpduXAn8yF7pDDub+GQMg@mail.gmail.com
[3] /messages/by-id/AMUA1wBBBxfc3tKRLLdU64rb.1.1683276279979.Hmail.wuhao@hashdata.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