Re: alter table set TABLE ACCESS METHOD - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: alter table set TABLE ACCESS METHOD
Date
Msg-id YLr7qZ9JWo2Q289u@paquier.xyz
Whole thread Raw
In response to Re: alter table set TABLE ACCESS METHOD  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
On Fri, Jun 04, 2021 at 05:34:36PM -0700, Jeff Davis wrote:
> I agree that a dummy AM would be good, but implementing even a dummy AM
> is a fair amount of work.

Not much, honestly, the largest part being to document that properly
so as it could be used as a template:
https://www.postgresql.org/message-id/YEXm2nh/5j5P2jEl@paquier.xyz

> Also, there are many potential variations, so
> we'd probably need several.

Not so sure here.  GUCs or reloptions could be used to control some of
the behaviors.  Now this really depends on the use-cases we are
looking to support here and the low-level facilities that could
benefit from this module (dummy_index_am tests reloptions for
example).  I agree that this thread is perhaps not enough to justify
adding this module for now.

> The table AM API is a work in progress, and I think it will be a few
> releases (and require a few more table AMs in the wild) to really nail
> down the API.

Hard to say, we'll see.  I'd like to believe that it could be a good
to not set something in stone for that forever.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: installcheck failure in indirect_toast with default_toast_compression = lz4
Next
From: David Rowley
Date:
Subject: Fix a few typos in brin_minmax_multi.c