sqlite file format, anyone?

[Matthew Vanecek]

On Mon, 2003-06-23 at 19:25, Derek Neighbors wrote:
> Matthew Vanecek said:
> > You lock a table in order to perform updates on the table, in the
> > absence of row or page level locks.  Standard DBMS practice.  Not a
> > design flaw--it's a feature, to prevent corruption of data.  Lock
> > tables, perform updates, unlock tables.  Anyone else will get a
> > contention error, and either retry their transaction or do other error
> > handling.
> 
> Well in my world locking a table causes grief beyond belief.  Page locks
> are ok, row locks preferred.  I think it is a design flaw to lock a table
> to update a row.  Thus I think in general MySQL as a choice is a design
> flaw, but I wanted to avoid that debate.  (See Mr. Browne's email earlier
> as I share his opinion on MySQL)
> 
> Please read I never said it was silly to 'lock' records, only silly to
> 'lock' tables.  There is a very significant difference.
> 

Indeed, and point well made.  However, if a DBMS only offers table-level
locking, then that's pretty much what you're stuck with.  MySQL has
table locks, according to the book, but I don't know about row level
locking.  Postgresql has the "SELECT FOR UPDATE" command that can be
used for explicit row locking.  The current PG back end uses table
locks--I want to replace those with row locks.  That will, of course, be
something that is pretty far removed from the engine->back end and
middle-ware layers.

-- 
Matthew Vanecek
perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
********************************************************************************
For 93 million miles, there is nothing between the sun and my shadow except me.
I'm always getting in the way of something...