Alvaro Herrera <alvherre@commandprompt.com> writes:
> Excerpts from Tom Lane's message of jue ago 19 23:35:06 -0400 2010:
>> While I don't care for having smgr.c call tablespace.c, moving the call to
>> md.c instead is surely not an improvement :-(. The problem here is that
>> we'd like the tablespace code to be above the smgr code, not below.
>> Calling it from md.c makes the layer inversion worse not better.
> I proposed moving that code to storage.c some time ago but was shot down
> for reasons I don't remember, and didn't press further. Perhaps the
> idea of moving it all to smgr.c/md.c for tablespace.c to call makes more
> sense; but if that doesn't happen, I still think that storage.c is a
> better place.
Hmm. I've never been terribly happy with storage.c: it doesn't have any
clear place in the layering, and looks like it's mostly code that has
been ripped out of smgr.c for no very defensible reason, and then moved
into catalog/ for even less reason. Maybe we should back up and rethink
the organization of all of smgr.c/md.c/storage.c.
The real underlying problem here is that there's so much stuff in
commands/ that is freely violating the smgr abstraction level by poking
at the filesystem directly. It's impossible to have a nice layering,
or even what you could call an abstraction, as long as things stay like
that. I guess it got that way because smgr.c was so useless that nobody
bothered to factor it in when thinking about how to implement
tablespaces and suchlike. But if we're going to do anything at all in
the way of cleaning up these interfaces, we need to start with a
redesign that re-establishes some clear division of labor.
regards, tom lane