Re: Table AM and DROP TABLE [ Was: Table AM and DDLs]

Now, suppose that we want to replace the storage layer with a different one. It is straightforward to replace it by implementing the Table AM methods above, but we are missing a callback on dropping the table. If we have that, we can record the table-to-be-dropped in a similar manner to how the heap AM does it and register a transaction callback using RegisterXactCallback.

This explanation makes sense, and the suggested patch makes it easier to replace the storage layer with a different one.

Some other places might become problematic if we're trying to implement fully memory-based tables. For example, the heap_create_with_catalog -> GetNewRelFilenode -> access() call that directly checks the existence of a file bypassing the smgr layer. But I think that adding a symmetric callback to the tableam layer can be a good start for further experiments.

Some nitpicks:

+	/*
+	 * This callback needs to remove all associations with the relation `rel`
+	 * since the relation is being dropped.
+	 *
+	 * See also table_relation_reset_filenode().
+	 */

"Remove all associations" sounds vague, maybe something like "schedule the relation files to be deleted at transaction commit"?

+	void        (*relation_reset_filenode) (Relation rel);

This line uses spaces instead of tabs.

For the reference, there is a recent patch that makes the smgr layer itself pluggable: https://www.postgresql.org/message-id/flat/1dc080496f58ce5375778baed0c0fbcc%40postgrespro.ru#502a1278ad8fce6ae85c08b4806c2289

--
Alexander Kuzmenkov
https://www.timescale.com/