Re: alter table set TABLE ACCESS METHOD

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>, pgsql-hackers@postgresql.org, Jacob Champion <pchampion@vmware.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Ashwin Agrawal <aagrawal@pivotal.io>, Ashutosh Sharma <ashu.coek88@gmail.com>, Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Dilip Kumar <dilipbalaut@gmail.com>
Date: 2021-06-05T04:21:35Z
Lists: 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

Commits

  1. Allow specifying an access method for partitioned tables

  2. Fix regression test output of sepgsql

  3. Add call to object access hook at the end of table rewrite in ALTER TABLE

  4. Fix typo in tab-complete.c

  5. Add support for SET ACCESS METHOD in ALTER TABLE

  6. tableam: introduce table AM infrastructure.