Re: embedded postgresql

Clinging to sanity, gevik(at)xs4all(dot)nl mumbled into her beard:
> I would like to know if there are any discussions about
> creating an embedded version on postgresql. My thoughts
> go towards building/porting a sqlite equivalent of pg.

People periodically "drive by" and suggest that PostgreSQL would
become fabulously better (or fabulously more popular) if it were
rewritten to do an in-process embedding of it.

There is little enthusiasm for the idea, as it would substantially
reduce the robustness of the system.

It also seems quite curious why in-process embedding should be so
attractive; it _looks_ as though most of the people that are so
excited about this idea have a pretty defective understanding of Unix,
and have missed the point that spawning extra processes to do
different kinds of work is a FEATURE.

The people with that defective understanding generally go away
unsatisfied.

If you really and truly want an "embedded" database, then you really
should look at Berkeley DB and SQLite. They may save you a bit of
memory if you only have one application that can make use of a
database. If you have a second application, or perhaps more than two,
it's pretty likely that linking to libpq and talking to a full-fledged
server will be a win.
--
(format nil "~S(at)~S" "cbbrowne" "ntlug.org")
http://www.ntlug.org/~cbbrowne/spreadsheets.html
... it's just that in C++ and the like, you don't trust _anybody_, and
in CLOS you basically trust everybody. the practical result is that
thieves and bums use C++ and nice people use CLOS. -- Erik Naggum