Dave Page <dpage@xxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
