How hard would a "no global server" version be?

From: Rob Browning <rlb(at)cs(dot)utexas(dot)edu>
To: pgsql-hackers(at)postgresql(dot)org, developer(at)lists(dot)mysql(dot)com
Subject: How hard would a "no global server" version be?
Date: 2000-08-28 20:49:06
Message-ID: 87r979jem5.fsf@raven.localnet
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


(Please cc: me in any replies. I'm not on the mailing list ATM, but
I'd be happy to subscribe if that's preferred or if this turns out to
be worth pursuing.)

We've been toying with switching to using SQL for the financial engine
in GnuCash for a while, and eventually we'll almost certainly add
support for an SQL backend as an option, but we haven't gone that
route yet because for individuals using the program (i.e. people who
just want something like Quicken/MSmoney/etc.), we don't feel it's
reasonable to require them to handle installing and maintaining an SQL
server just to do their checkbook.

However, if, for the single users, we could find an SQL system that
would (like sleepcat) allow us to keep the database in a local file,
and not run a global server[1], we'd be set. We could use that for
single-users and then support maxsql/postgresql for users who
want/need more power.

[1] If a one-process solution would be too hard, we'd probably be fine
with hacks like just automatically launching the server as the
user whenever the user launches the app, and then having that
dedicated server talk to the app exclusively via FS sockets or
whatever, and manage its database in one of the user's
directories.

So what I'd like to ask is this:

(1) Are there any plans to add anything like this?

(2) How hard do you think it would be for an outsider to add this
feature as an option, and if someone did, would you be likely to
be interested in incorporating the result upstream?

Thanks

--
Rob Browning <rlb(at)cs(dot)utexas(dot)edu> PGP=E80E0D04F521A094 532B97F5D64E3930
<rlb(at)debian(dot)org> <rlb(at)gnumatic(dot)com> <rlb(at)gnucash(dot)org>

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-08-28 21:05:10 Re: SQL COPY syntax extension (was: Performance on inserts)
Previous Message The Hermit Hacker 2000-08-28 19:16:25 Re: Re: Too many open files (was Re: spinlock problems reported earlier)