Re: smgr.c and smgrtype.c - Mailing list pgsql-hackers

From Tom Lane
Subject Re: smgr.c and smgrtype.c
Date
Msg-id 12770.1098170876@sss.pgh.pa.us
Whole thread Raw
In response to smgr.c and smgrtype.c  (Satoshi Nagayasu <nagayasus@nttdata.co.jp>)
Responses Re: smgr.c and smgrtype.c
List pgsql-hackers
Satoshi Nagayasu <nagayasus@nttdata.co.jp> writes:
> I'm trying to modify the storage manager now.

Um ... why?

There is no doubt that the current smgr interface leaves a lot to be
desired, but the reason that it's in such sad shape is that there is
absolutely no modern-day use for an API at that particular level of
abstraction.  The stuff that the Berkeley boys and girls envisioned
doing here has all migrated down into the kernel, if not clear down
into the hardware (think RAID controller).  Most of the stuff that
people would now like to have an API separation for is at much higher
levels of abstraction.  For example, the smgr API doesn't even know what
a tuple or an index *is*, much less have the potential to modify lookup
or locking or replication semantics.

If anyone had wanted to add a new storage manager in the last fifteen
years, we'd doubtless have tried to clean this up some, but no one has
and I'm not really expecting anyone to try in the next fifteen...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Neil Conway
Date:
Subject: Re: 7.4 changes
Next
From: Satoshi Nagayasu
Date:
Subject: Re: smgr.c and smgrtype.c