Re: virtual filesystem atop a PostgreSQL database

Hmm, filesystem IS database.
If you need SQL-like functionality to ask  for something in your fs why do
you want to mount db like fs?
You can build a sql-like shell !?! EnhancedBASH?


JP

On Tue 25. September 2001 14:22, you wrote:
> 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster