Re: [Monotone-devel] PostgreSQL support

[Nathaniel Smith]

On Tue, May 11, 2004 at 12:30:56PM -0400, joel reed wrote:
> On Tue, May 11, 2004 at 01:11:38AM -0700, Nathaniel Smith wrote:
> > On Mon, May 10, 2004 at 02:51:57PM -0400, joel reed wrote:
> > > how interested is everyone in PostgreSQL support? don't want to work
> > > too much on this if there's only marginal interest.
> > 
> > Maybe you could say something about what the motivation would be?  I'm
> > not saying it's bad, just no obvious advantages jump out at me, so I'm
> > curious what advantages you perceive.
> 
> i had 3 reasons.
> 
> 1) much more familiarity and comfort with PostgreSQL than SQLite, 
> regarding tools, drivers, scalability, etc.
> 
> 2) the customized SQLite page size seemed to make mono's SQLite driver
> barf, which made me concerned about interoperability with other SQLite
> drivers, like SQLiteODBC.

This doesn't seem like that big concern to me.  It's great for
emergencies that Monotone repositories can be gotten at with raw SQL,
but aside from such exceptional situations, you really don't want to
go poking around in there by hand.  The storage representation is
somewhat idiosyncratic, has changed in the past, and is liable to
change in the future.  You already have to be able to read Monotone's
proprietary delta format, for instance, to get useful file/manifest
data out of it.

So the point is, interoperability, availability of tools, etc. are
mostly irrelevant; better to just improve Monotone's scriptability.
As for scalability, SQLite seems able to handle the GCC repository
with some aplomb, so I don't know that I'd be too worried; in general,
SQLite is much _faster_ than other databases.

> 3) i was intrigued by the possibilites of exposing a single
> PostgreSQL repository to multiple monotone clients, rather than exposing
> a monotone server.

Intriguing, I agree, but I'm not sure what the practical use would be?
One of the flaws in CVS is that to give someone (remote) write access
to the repository, you basically have to give them full write access
to the actual files that compose the repository, meaning they can
spoof things, change history, etc. -- big security hole.  Monotone's
compulsive RSA signatures provide some deterrence against this, but
if you can access a db directly, you can still do things like delete
versions, corrupt the database, what have you.  (Does Monotone
necessarily notice if you've somehow managed to store a manifest_id ->
manifest mapping in which SHA1(manifest) != manifest_id?)  If you give
people netsync access, they can't do that; all they can do is add new
versions.  So netsync is a considerably safer architecture for
collaboration than direct sharing of the underlying database would be.

-- Nathaniel

-- 
"...these, like all words, have single, decontextualized meanings: everyone
knows what each of these words means, everyone knows what constitutes an
instance of each of their referents.  Language is fixed.  Meaning is
certain.  Santa Claus comes down the chimney at midnight on December 24."
  -- The Language War, Robin Lakoff