virtual filesystem atop a PostgreSQL database

From: Frank Joerdens <frank(at)joerdens(dot)de>
To: pgsql-general(at)postgresql(dot)org
Subject: virtual filesystem atop a PostgreSQL database
Date: 2001-09-25 12:22:44
Message-ID: 20010925142244.B6812@rakete.joerdens.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

I am wondering whether anyone has already tried it, or if not, looking
for starting points as to how to go about doing it:

The idea would be to have some kind of tree implementation (e.g.
pointers or nested sets) for an SQL database and then to write a Linux
driver that would make it possible to create a device file so that you
could do something like

mount -t (specify filesystem: e.g. ext2, vfat) /dev/posttree /mountpoint

so that the SQL tree would look like a normal filesystem. Read-only
would be cool to start with, although it'd become really useful if you
had an rw implementation with permissions etc.. (Richard Jones has done
something which is kind of similar for his ftp server: You can use a
PostgreSQL database as a backend for it, rather than a filesystem:
http://www.cpan.org/modules/by-authors/id/R/RW/RWMJ/)

How difficult would that be? Where to start? Where to find code snippets
to work with? Which filesystem would be the most suited for an emulation
- ext2,vfat . . . ? Whould that need to be done in C or could you write
a wrapper/driver in something like e.g. Perl?

The inspiration for this idea was Hans Reiser's manifesto 'The Naming
System Venture' where he argues that the future belongs to filesystems
with database-like extensions, rather than databases. He may be
right or not; but what kept me thinking above all was that I
do encounter the problem that he describes: Whenever I want to put
something into a database, or retrieve something from it, I am always
depending on more or less specialized interfaces (I use PHP) which may
not be available to some user at some point, and things then tend to
become cumbersome. Hans Reiser's argument is actually somewhat more
sophistaced and lenghty, which is why I am not trying to reproduce it
here. A tool like the one I tried describe would make it possible to
combine the flexibility of a filesystem with the more specialized
functionality of an SQL database.

Regards, Frank

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Mike Arace 2001-09-25 12:42:04 Encoding passwords
Previous Message Nicolas Milet 2001-09-25 12:12:01 PgSQL behind a firewall