Re: small smgrcreate cleanup patch

On Thu, Aug 19, 2010 at 11:35 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.
>
>> You could argue that perhaps md.c isn't the right place either, but it
>> certainly makes more sense than smgr.c, and I'd argue it's exactly
>> right.
>
> On what grounds pray tell?

If smgr wants to even have the pretense of being an abstraction layer,
it can't very well know about the underlying file system structure.
But there's no getting around the fact that md.c has to know that
stuff; it has to create and write those files. There is, perhaps, a
layer inversion problem here, but if anything I think it's that the
functionality of tablespace.c spans everything from the SQL layer all
the way down to pushing bits in the filesystem. But that's not really
the fault of smgr.c/md.c. Perhaps tablespace.c shouldn't assume
anything about the underlying filesystem representation and that
knowledge should be moved somewhere under src/backend/storage, but I
don't see how it makes sense for the smgr layer to include assumptions
about what filesystem abstraction md.c happens to implement.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company