On Fri, Jan 5, 2018 at 7:20 PM, Robert Haas <robertmh...@gmail.com> wrote:
> 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. Good point, thank you for noticing that. Name "storage" is really confusing for this purpose. > 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. I would vote for the first proposal: table AM. Because we eventually might get index-organized tables whose don't have something like heap. So, it would be nice to avoid hardcoding "heap" name. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
