On Thu, 4 Jun 2026 at 04:32, Andrew Dunstan <[email protected]> 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+g...@mail.gmail.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. > > cheers > > > andrew > > > -- > Andrew Dunstan > EDB: https://www.enterprisedb.com > -- Regards, Rafia Sabih CYBERTEC PostgreSQL International GmbH
