Dave Page <dpage@pgadmin.org> writes:
> Hmm, I think I misread Thom's question. The smgr API used to be far
> more rigidly designed as I understand it, to allow the possibility of
> having different storage engines (for example, maybe one that used raw
> devices). I don't know that any other storage engines were ever
> actually written though.
There actually were two smgr storage modules in the code we inherited
from Berkeley, and I think there were probably more at one time. But
the smgr interface is *way* lower level than mysql's storage engines;
there is not that much that you can do to affect the behavior of the DB
by replacing an smgr module. I believe what they had in mind originally
was to be able to drive different physical storage devices, using raw
access instead of going through the filesystem. That decision was taken
before everything of interest got unified under the Unix filesystem API.
These days, if you needed to do what they had in mind, you'd be writing
a kernel device driver instead. So smgr is pretty vestigial, and we've
largely broken its API abstraction anyway by doing filesystem access
directly in so many other places.
regards, tom lane