I do not like the way that this patch set uses the word "storage". In current usage, storage is a thing that certain kinds of relations have. Plain relations (a.k.a. heap tables) have storage, indexes have storage, materialized views have storage, TOAST tables have storage, and sequences have storage. This patch set wants to use "storage AM" to mean a replacement for a plain heap table, but I think that's going to create a lot of confusion, because it overlaps heavily with the existing meaning yet is different. My suggestion is to call these "table access methods" rather than "storage access methods". Then, the default table AM can be heap. This has the nice property that you create an index using CREATE INDEX and the support functions arrive via an IndexAmRoutine, so correspondingly you would create a table using CREATE TABLE and the support functions would arrive via a TableAmRoutine -- so all the names match.
An alternative would be to call the new thing a "heap AM" with HeapAmRoutine as the support function structure. That's also not unreasonable. In that case, we're deciding that "heap" is not just the name of the current implementation, but the name of the kind of thing that backs a table at the storage level. I don't like that quite as well because then we've got a class of things called a heap of which the current and only implementation is called heap, which is a bit confusing in my view. But we could probably make it work. If we adopt the first proposal, it leads to another nice parallel: we can have src/backend/access/table for those things which are generic to table AMs, just as we have src/backend/access/index for things which are generic to index AMs, and then src/backend/access/<am-name> for things which are specific to a particular AM. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
