From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <031b381fadb797cae6506e8db8b1285f@quanstro.net>
To: 9fans@9fans.net
From: erik quanstrom <quanstro@quanstro.net>
Date: Fri, 21 Nov 2008 12:18:48 -0500
In-Reply-To: <e1d437a40811210905h3472f836rc3d61fb323a30ba4@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: Re: [9fans] web-based plan 9?
Topicbox-Message-UUID: 4f9045c6-ead4-11e9-9d60-3106f5b1d025

>    - 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