Many have expressed their interest in this topic, but I haven't seen any design of how it should work.
That's it. My design presented at PGCon was very sketchy, and I didn't deliver any prototype yet.
Here's my attempt; I've been playing with this for some time now and I think what I propose here is a good initial plan.
Great! It's nice to see you're working in this direction!
This will allow us to write permanent table storage that works differently than heapam.c. At this stage, I haven't throught through whether this is going to allow extensions to define new storage modules; I am focusing on AMs that can coexist with heapam in core.
So, as I get you're proposing extendability to replace heap with something another
but compatible with heap (with executor nodes, index access methods and so on).
That's good, but what alternative storage access methods could be?
AFAICS, we can't fit here, for instance, another MVCC implementation (undo log) or
in-memory storage or columnar storage. However, it seems that we would be
able to make compressed heap or alternative HOT/WARM tuples mechanism.
Correct me if I'm wrong.
ISTM you're proposing something quite orthogonal to my view
of pluggable storage engines. My idea, in general, was to extend FDW mechanism
to let it be something manageable inside database (support for VACUUM, defining
indexes and so on). But imperative was that it should have its own executor nodes,
and it doesn't have to compatible with existing index access methods.
Therefore, I think my design presented at PGCon and your current proposal are