[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sylpheed
Subject:    [sylpheed:10998] going seriously off-topic
From:       Bob Forsman <thoth () purplefrog ! com>
Date:       2002-02-27 15:51:46
[Download RAW message or body]

On Wed, 27 Feb 2002 00:53:49 -0600
Ron Johnson <ron.l.johnson@cox.net> wrote:

> Then you use the wrong databases.

  Heh.  "wrong".  vi is the wrong editor for hacking lisp, and emacs
is the wrong editor for tweaking the fstab.

  I've deployed Oracle (experimentally) once.  It was a giant pain in
the ass.  Postgresql is (comparatively) a walk in the park: "CREATE
DATABASE foo;".

> >   4) Databases are not terribly standardized in how they store large
> > objects (which is anything more than 8K in postgres, I don't know what
> > the boundaries are for Oracle and other databases).
> 
> ????  You think databases only store structures up to PAGE_SIZE in size?
> Again, you use the wrong databases.

  Nope.  You misunderstood which boundary I was talking about.  I was
talking about the boundary between the size of things that can be
represented by regular types (like varchar, or postgresql's text) and
those that have to be represented by large objects and require special
APIs to access.

  Would *you* encourage programmers to use rs.getString(3) for a 1.5 megabyte column?

> [snip]
> >   If you really want a brain enema, read some of Reiser's essays
> > (which propose giving the filesystem database-like qualities).
> 
> What's wrong with them?

  They don't fit in the little box of POSIX filesystems that I've been
working on since '88.

>  Imagine grepping a "database"...  

  I like that imagination, but how do you specify to grep which
columns you are interested in?  I wish I had a stipend to play with
solutions.

> Although, Reiser isn't the only one with this idea.  According
> to theregister.co.uk, MS' next filesystem will really be SQL-Server.

  Cute; I guess since they've lost the desktop with their XP licensing
practices, they can go for server-type hacks.
[prev in list] [next in list] [prev in thread] [next in thread]