> - a "ctrl" file which accept only COMMIT, ROLLBACK and ABORT > - an "error" file > - a "notice" file (postgresql has RAISE NOTICE... may be others have it > too) > - a "data" file (append only in the transaction, but not outside) where > the INSERT, UPDATES, DELETE and all the DDL and DCL commands will be > written > - each SELECT have to be written in a different file (named
databases seem pretty far outside 9fans territory and design on a mailing list doesn't seem like a good idea ... but anway, i hope this comment is more strategy than design and a bit more general. since a relational database isn't imperative thing, i have never understood having a imperative interface to one, especially an unconstrained interface. if you have a problem big enough to warrant a database, it will get refactored, rekeyed, renormaled &c. it's quite unattractive to have a database reorganization escape and force changes in imperative code. i think a declarative interface would make much more sense — as in i want a new user fred with properties x, y, z instead of begin transaction .... if you're going to put up with a database, it needs be a big boy and take care of itself. would you put up with a file system that required you to do the locking and inode allocation yourself? - erik
