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

Поиск
Список
Период
Сортировка
От Rob Browning
Тема How hard would a "no global server" version be?
Дата
Msg-id 87r979jem5.fsf@raven.localnet
обсуждение исходный текст
Список pgsql-hackers
(Please cc: me in any replies.  I'm not on the mailing list ATM, butI'd be happy to subscribe if that's preferred or if
thisturns out tobe 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
theserver as the   user whenever the user launches the app, and then having that   dedicated server talk to the app
exclusivelyvia 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
yoube likely to     be interested in incorporating the result upstream?
 

Thanks

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930    <rlb@debian.org> <rlb@gnumatic.com>
<rlb@gnucash.org>


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alfred Perlstein
Дата:
Сообщение: Re: INHERITS doesn't offer enough functionality
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Re: UNION JOIN vs UNION SELECT