fs+sql - Mailing list pgsql-hackers

Hello ! 

I've written a small description of the project I would like to work on,
and since it involves Postgres , decided to ask for a feedback
from the people who can help . Thank you :). 

The Problem :
Automate database-oriented development.
Solution : automate representation of relational data and methods of access 
to
the collections of data on the filesystem.
Requirements : represent data in a file-like manner , so any process, using
"open() , read(), write () , mknod() chmod()" and other fs operations would 
be
able to read/write db data, without knowledge of DB layer using fuse
(http://sourceforge.net/projects/avf) and Postgres:
http://www.postgresql.net). Fuse-level plugin code
is aware of environment variables database it is accessing - such as tables 
,
some of the input-ouput functions of the DB and tables, thus , allowing
translations of filesystem read() into the corresponding DB-level read() on
the fly. DB-level read is generated , or written functions for accessing
objects in db. Depending on the mount options of the database and access
levels and types specified - the database can be mounted using different
views on the file system : In case failure access functions get the usual
filesystem errors+possibly DB-level exceptions.
The following are parts that need to be written : 

1. Postgres-level code :
a. code that generates/regenerates dependencies
in the case of change ( default "open" , "read", "write" procedures for
each db object). By gettig db objects info from systables - generate xml
description. In case of readdir() "table view" - it is de-xmlized "list of 
files", in
case of ouput to html directoy - html'lised version for "open" 
"read","write"(?).
Also generate default perl/xml? functions to convert incoming
const char* into xml structure and generate sql insert into table( case 
write),
and stream xml as const char* in case of read. 


b. code that generates "views" for particular type of mounts and access.
(most likely - using xslt, xml and perl ) ?
example : for mounted into the filesystem (/mnt/db1) as files
database db1, corresponding tables are mapped into
/tmp/db1/table1 /tmp/db1/table2 .
example 2 :
for mounted into fs as html files - on the 'read' operation against
index.html , for example , or login.html the 'html-view' code
would create xml file and then , applying xslt - html, or multiple
htmls and cache them into the directory. 

c. Also caching , mount and update options( triggers ?) 

2. Fuse plugin code :
code that translates following calls into db-level operations :
getattr,
readlink .getdir , .mknod .mkdir .symlink .unlink
.rmdir .rename .link .chmod .chown .truncate .utime
.open .read .write .statfs .release .fsync 

Some of them are directly translatable into permission functions - chmod,
chown , some into types of access - unlink, read, write . I think all file
operations should find themselves in the db's methods (one or another way),
To do that we need to have generated "beforehand" "input/ouput" level
functions, that know how to "parse" (const char*) that is passed by 
virtually
all of the functions into corresponding "select, update , insert". Thus ,
read function against the file , which is table would return table.read()
operation , which does "select" based on buffer size and other params of
"read". 

Real-life example : Logging 

Lets say that the code is written and working - what would I expect to do 
with
such functionality : 

mv -R /var/log /var/log.old :
pgmount -fs -d syslog /var/log 

After restarting syslogd - the same filestructure you had before in /var/log
in syslog database in the relational tables (1 to 1) correspondence.
So , that from syslogd' point of view nothing has changed.
In the database besides tables , in "known" format , there are "open , read
write" functions per each table , or per each dir (db) depending if formats
same/different in this dir. With all the work in fuse-pgsql layer. 

Similar to this example , would probably be "Man" database , with special
generated /usr/bin/man.db or (man.db) which is mounted and takes care of
translating special options like "man -k" and so on.
"/proc" for kernel ? 

3. Caching and input/output options/plugins that improve in-memory
operations , similar to loopback tcp/ip .
Since database "generates" data, it is aware for which "representation"
it has generated this data piece , so it will stamp it with memory TTL. 


Please share any thoughts you will regarding this project/description.---------------------------------