Re: [HACKERS] Pluggable storage

On Fri, Jan 5, 2018 at 7:20 PM, Robert Haas <robertmhaas(at)gmail(dot)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